As far as I know, regarding web-roles, it is possible to have multiple ServiceConfiguration.cscfg files, one for each publish profile (for example, Cloud1, Cloud2, Cloud3, Local and so on).
Though, is it possible to have different diagnostics.wadcfg (wadcfgx) files?
How to instruct Visual Studio to use a specific diagnostics file when deploying to Azure? Is there a specific entry in the publish profile XML file?
Out of the box, it is not possible because there can be only one diagnostics.wadcfg (wadcfgx) file associated with a role in a cloud project a cloud project.
We are using SDK 2.4 in our project and the way we have worked around this problem is by creating separate cloud projects for each environment - Dev, Staging, and Production. Since these are separate cloud projects, we can have different diagnostics configurations.
If you're using SDK 2.5, one thing that works in your favor is the diagnostics is now an extension (instead of plugin). What that allows you to do is change/enable/disable diagnostics on the fly. Though I have not tried it but one thing you could possibly do is enable diagnostics as a part of your deployment process. By default there won't be any diagnostics.wadcfgx file in your project. When you deploy your code via PowerShell, after successful deployment, you can enable this extension. Please see Step 4 here: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/#worker-role. (Since I have not tried it myself, I would be very much interested in knowing the outcome. Please do share if this approach worked for you).
Related
I just started working with EPiServer (Sitecore before) and looking for a way how to synchronize content between environments automatically (developer-developer and developer-QA env).
We have our QA environment on an azure virtual machine and need to synchronize content during CI/CD.
EPiServer DXC Service doesn't meet the requirements because we are not working on a web app service.
Any ideas? Is there any already existing way to achieve it?
Automatic synchronization between environments has [more-or-less] gone away within the Episerver platform. The old way of doing this was using mirroring, but that's not available in the DXP, and is eventually being removed from the platform in favor of other strategies:
For moving bulk data (content items, content types, categories, visitor groups, etc.) between different environments, without touching code or the database, use the "Import Data" and "Export Data" tools within Admin mode. More information here: http://webhelp.episerver.com/latest/en/cms-admin/exporting-importing-data.htm
For bigger bulk migrations of data between environments, typically a database backup and restore is done between environments. Obviously, this is a bit more risky when involving a production environment.
If the content (or a content type change) is required as part of a deployment, you can build a content migration step. More information here: https://www.gulla.net/en/blog/renaming-an-episerver-page-property-using-a-migration-step/ and https://world.episerver.com/documentation/developer-guides/CMS/Content/Refactoring-content-type-classes/
If you are simply wanting to move authored content from a staging environment to production, it's suggested to create all content in production and use Episerver's Projects feature. More information here: https://webhelp.episerver.com/latest/en/cms-edit/projects.htm
If you are using Azure DevOps for CI/CD you might want to look into Epinova DXP Extension to Azure DevOps - that uses the Episerver deployment API but makes this easier to set up your pipelines. See https://www.epinova.no/en/folg-med/blog/2020/episerver-dxp-content-harmonization-with-epinova-dxp-deployment/ for more info.
Take a look at the Deployment API. There might be something in there for you. https://world.episerver.com/documentation/developer-guides/digital-experience-platform/deploying/episerver-digital-experience-cloud-deployment-api/
I have made a task for Azure Devops Server pipeline.
On the local Azure Dev-Ops server, I can upload extensions from the local machine wrapped in VSIX file and examine the agent on the machine itself. The agent has the deployed DLL's from the extension and I always change specific DLL that has Logger inside and it prints to console on the pipeline itself.
How can I check if my task is compatible with the cloud version?
And off course if it is, how can I debug it?
The only possible way I found to insert my task in VSO is through the Microsoft DevOps marketplace, but I cannot upload the whole extension once per each change in code.
Also, didn't find a way to upload personal tasks to the marketplace. The private version is not helping because I can see it from within the server just like my clients.
Any advice or debug experience on that platform is appreciated.
Please follow this devblogs, it described how you can work and debug extension directly inside your IDE without publishing it to the marketplace.
Since this blog is very detailed, just mention the key steps.
Based on debugging purposes, you need create a special manifest, for sample I specify it as vss-extension-debug.json:
{
...
"id": "dev-extension",
"name": "Dev-Extension",
"baseUri": "https://localhost:44362",
...
}
You can customized the id and name by yourself. The most important and magic is baseUri, this will tell the VSTS server to load the extension from localhost where we can run and debug it in IISExpress from Visual Studio.
Note: Since our server need extension served from a secure source, please ensure enable SSL mode to run IISExpress
So I have been banging my head against a wall on this one...I am trying to publish an Azure Web Role and I have two ServiceConfiguration files:
ServiceConfiguration.Cloud.cscfg
ServiceConfiguration.Local.cscfg
In my publish xml I have:
<AzureServiceConfiguration>Cloud</AzureServiceConfiguration>
So my assumption here is that when I publish it will use the Cloud cfg.
For working locally, under the emulator I have set the flag for local debugging to use Local.
However it would seem that this flag here also determines the cscfg to use for the cloud...so I am a little confused - is this the correct behavior or am I missing something? I really want to have a separate one for local as I have different values I need.
Update
Suddenly it started to work fine today. Didn't really change anything.
Tom, your publish XML configuration file is OK, and your publish to Azure will use the .Cloud.cscfg.
You can pick which of the configuration files you want to use when publishing (right click > Publish...), on the second screen (under Service configuration).
What you did for your local environment should work fine, and use the .Local.cscfg file.
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH