I've just been upgrading an Azure project to Visual Studio 2010 and have been taking advantage of the new XML configuration transformation feature that is built into VS2010 web projects. It seems to work great with Azure web roles. I even managed to get the Azure project service configuration file to do a similar thing by following the instructions here.
However, I can't seem to get configuration transformation working for the lone worker role in my Azure project. I know that VS2010 only has built-in support for config transformation with web roles, but I found a good article describing how to get config transformations working with non-web projects. I've followed the instructions and it works - but only to a point. It successfully spits out the correct .config file (with appropriate transformations) into the worker role project's own bin directory, but it doesn't pick this new .config file up when it's put into the cloud package.
I suspect there's some MSBuild trickery needed to get this to work, but I don't know MSBuild very well, so am appealing to any gurus out there for help and/or samples :)
I have found the best way to do this is to use msbuild. I usually do this with a separate msbuild file outside my solution so I keep the local dev settings separate from the production settings. You can find out more here. I then can run the build to change the settings and upload the project to Azure. I can also run this to change the settings and then run deploy through VS if I need to debug the problem. I also have a target in the msbuild file that then can revert everything back to local. It would be nice to have these things in VS (which I have asked for from the product team). The sample project is on github.
This is also explained in the book we wrote in the Life Cycle chapter.
Related
We have a C# .NET project using Visual Studio 2013 and we're setting it up to release and deploy with Visual Studio Team Services (VSTS). The websites were pretty simple and easy to set up and they work fine. A few projects are libraries or Console applications and we're trying to determine the best method for creating an automated release for these.
The publish profile asks for a location to publish to - we've experimented with the build drop on our VSTS build server (where all of the other files are) and then asks for a website, a UNC path or a CDROM. We chose "UNC Path" and put the same build drop location in, but in UNC format.
It hasn't really worked yet, so I thought I would see if any best practices for creating VSTS releases and deploys for Console or Code Libraries exist.
Thank you!
Have you considered installing the agent on the target environments and using a release definition that simply copies the right files at the right place?
Regards
Note: copy path shouldn't be hardcoded and rely on variables.
To specify the agent queue by going to the tasks tab when editing the release definition. Click on the "run on agent" header, that will open the details, select your queue here.
Agent queues can contain multiple agents, so your job when you add agents is to organize them by queues that make sense in your context.
We have several Web Apps and WebJobs with different configurations for different environment, e.g. Test and Release.
Each WebJob is deployed to a Web App using "Publish as Azure WebJob" in Visual Studio.
We are using the Config Transform extension to transform the App.config that consist of different config sections, connection strings and app settings that needs to be transformed. This works fine for local Debug and for Release.
The problem is that when we use "Publish as Azure WebJob" there is no way to specify which configuration to use and Release is always built and published even if Test is selected inside Visual Studio.
We have also tried to deploy the WebJob together with the Web App but it almost always hangs, same as described in Stuck when publishing Web App to Azure with WebJob
We don't need to use config transform if that's not possible, e.g. we could configure directly in Azure. But I haven't found a way to configure config sections directly in Azure.
Yes this is a known VS tooling pain point that comes up often. The short answer is that web.config style transforms aren't supported for general application types like Console apps.
This has been discussed recently in the context of WebJobs in our public repo here. That issue also links to the VS User Voice issue for this. That item also links to the SlowCheetah VS extension which some users have said works for them. You might give that a try.
If that doesn't work for you, then you'll have to manually manage your settings via the app settings blade in the Azure portal.
I added a prebuild step to change the webjob-publishing-setting.json file and the app.config file depending on which Configuration is selected.
The webjob-publishing-settings.json only had the name. Then from Visual Studio 2019 I used "Publish as Azure WebJob" and that created a second webjob with the new name and new configuration.
Works great!
I'm deploying from Visual Studio to an Azure instance as part of a small team, and we've found that deployment behavior depends on which machine was last used to deploy.
If we change which machine we deploy from, the deployment updates a large list of DLLs and CSS files, even though they're unchanged from the previous deployment. If the same machine is used more than once, all deployments after the first are smooth and take very few updates.
Is there a known reason for this behavior that I've been unable to find, and is there a way to avoid updating unchanged files?
While deploying manualy from Visual Studio is nice for getting a prototype working, it isn't consired as best practice to build and deploy from a local development machine, since the result strongly depends on how the local machine is configured, which DLLs are in GAC, etc... This may also be one of your problem, but this is realy hard to debug.
So I strongly recommend either using deploy through source control or using a build server like TeamCity, Jenkins or similar to deploy.
Deployment with source control are realy easy to setup. You can follow the this guide in order to get started.
Can anyone shed some light on how to get Team Build 2010 beta 2 to push a SQL database project to the SQL server?
In VSTS 2008 you'd just add MSBuild commands with the targets attribute set to "deploy" in the TFSBuild.proj file, but I'm having a little trouble translating that to the new workflow based xaml thing that 2010 uses.
What I'm looking for is how to trigger the actual deployment of the databases themselves. It is already generating the deployment scripts just fine.
For anyone still looking for the answer, use an Invoke Process that uses vsdbcmd.exe:
http://msdn.microsoft.com/en-us/library/ff805001.aspx
Here is an example:
http://www.nablasoft.com/alkampfer/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
It may be that you are simply missing the DeployToDatabase=true
There is another solution to this problem if you don't need incremental database upgrade. So if recreating the database for each build is ok with you the following would also work.
Add a deploy target to Database Project file
Configure the deployment settings for ‘My project settings’. Those settings will then be used by the build server when building the solution. When building locally, the settings used will be the ones from ‘My isolated development environment’.
In the database project properties
Deploy Action needs to be ‘Create a deployment script (.sql) and deploy the database’; this will prevent the execution of the script, it will only create it.
Database project file
Modify the database project file (right-click database project, select Unload, right-click again, select Edit [ProjectName].dbproj)
from
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
To
<Project DefaultTargets="Build;Deploy" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
When the Build server builds the solution containing the database project, adding the default targets will also deploy the database. This build will use the Deploy settings selected for ‘My project settings’.
Pros
Easy to set up
Cons
Because the default target is changed to Build and Deploy, when a developer do a local Rebuild of the solution, it will also deploy the database (building only won't trigger the deployment)
The closest thing I've found so far is this post from Jim Lamb (the Team Foundation PM at Microsoft).
Here he talks vaguely about creating a custom proj file and modifying the default build process template to invoke the proj file.
He also talks about using the upgrade template, which I'd previously ignored. Apparently the upgrade template can be used to invoke a 2008 build definition. I'd rather not invoke and define the entire build based on the legacy proj file though, but at least it is an option.
Neither topic contains sufficient information for me to actually make the modifications necessary, but it does give me a reasonable starting point for some future experimentation.
I'm working in a team environment where each developer works from their local desktop and deploys to a virtual machine that they own on the network. What I'm trying to do is set up the Visual Studio solution so that when they build the solution each projects deployment is handled in the post-build event to that developers virtual machine.
What I'd really like to do is give ownership of those scripts to the individual developer as well so that they own their post build steps and they don't have to be the same for everyone.
A couple of questions:
Is a post build event the place to execute this type of deployment operation? If not what is the best place to do it?
What software, tools, or tutorials/blog posts are available to assist in developing an automatic deployment system that supports these scenarios?
Edit: MSBuild seems to be the way to go in this situation. Anyone use alternative technologies with any success?
Edit: If you are reading this question and wondering how to execute a different set of MSBuild tasks for each developer please see this question; Executing different set of MSBuild tasks for each user?
If you are using Visual Studio 2005 or later, project files are MSBUild files. Inside the MsBuild file, there is an "AfterBuild" target. I would recommend using this to do your deployment tasks, instead of the Post Build Event.
By using MSBuild tasks, you are more prepared to move into a Continuous Integration system like CruiseControl.NET, or Team City.
I'm not sure why all of your developers have their own virtual machines, it would seem at some point you'd want a central location where all developers work is built to ensure the code from all developers will integrate and build (this is a reason for using Continuous Integration systems). I'm sure you can find a way that CruiseControl.Net or Team City or one of several other choices can help you in this scenario. But as far as getting the initial setup, use MSBuild.
i'd look into MSBuild or ANT