My approach here may be wrong, so apologies if so - I'd appreciate any advice on what I did wrong.
I need to run (locally, for debugging), a specific configuration of a project that contains specific web.config transforms.
In my solution, in Configuration Manager I have the following listed:
Debug
Release
ClientFoo (copied from Release)
ClientBar (copied from Release)
I created a new entry, ClientXYZ (copied from Debug), then right-clicked web.config and chose Add Config Transform. I applied the transform rules, and when previewed, the transforms display correctly.
When I select ClientXYZ in the solution config drop down, and start the debugger...
...I see that the web.config used to initiate the application is the Debug one, and not my new ClientXYZ version.
Is it possible to run the project locally with web.config transforms applied, for debugging?
Web config transforms are only applied during publishing or building deployment packages by default (it does, after all, overwrite web.config). There is a way with some adjustments, however, described in this answer: https://stackoverflow.com/a/35561167/1464084
The purpose of using "Debug" and "Release" in Visual Studio are:
Debug constant defined in Debug configuration when you are developing application
Release optimize code enabled in Release configuration when you host that application for client side testing or publishing
Custom (ClientXYZ) constant defined for a developer's own settings (localhost or different IP's) for both Client site hosting and publishing your site
Related
Suppose I have a web.config parameter under <appSettings><add key="myParam" value="myValue"/></appSettings> and I want to modify the value for myParam depending on the publish profile I use, ie DEVELOPMENT.pubxml and TEST.pubxml for a web site deployment.
What is the most straightforward way to accomplish this? How do I specify in the pubxml which keys I want to transform, where they are, etc?
Either a direct answer or a link to a resource that answers this question would be highly appreciated.
You can create Web.config transform files for publish profiles as well as for build configurations. When you publish, either in Visual Studio or from the command line, Visual Studio applies both the appropriate build configuration transform and the publish profile transform. See this tutorial:
http://www.asp.net/web-forms/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
This is one of a series of tutorials. Others in the series run through examples of creating publish profile transforms and examples of doing it from the command line.
The tutorials use a web application project. If by web site deployment you mean you're deploying a web site project, the process is basically the same as long as you have installed the latest VS update (see the first tutorial in the series for links to the VS update).
We essentially have two separate development paths:
Local → Dev → QA → Prod
Local-Release → Dev-Release → QA-Release → Prod
The first path uses our mainline/trunk, the second path is for when we cut a release branch and need to make bug fixes in between releases.
We use config transformations for Dev, QA, Prod, Dev-Release, and QA-Release and this all works great. However, after each time we cut a release branch, we have to manually change the config files for the Local-Release environment (things like changing the connection string from using LocalDB to LocalReleaseDB, etc).
It would be ideal if we could automate this using another transformation file, but we're not publishing anywhere. Is there a trick to get around this? Could we do it at runtime or have a powershell, batch file, or something else run after creating the branch? What do others do to accomplish this?
I believe that SlowCheetah will give you what you need.
Taken from the SlowCheetah website:
This package allows you to automatically transform your app.config (or any file) when you press F5 in Visual Studio. You can have different transformations based on the build configuration. This will enable you to easily have different app settings, connection strings, etc for Debug versus Release. If you want to transform other files you can do that too.
I haven't ever tried this in a TFS build scenario, but as long as SlowCheetah is installed on the build servers, I guess it would work.
I believe I found a viable solution here: http://kfigy.blogspot.com/2010/03/making-visual-studio-2010-webconfig.html
He's using the approach to allow multiple developers to each have their own config settings, but it can also be used to have config settings per branch.
Let's pretend that we have the following servers [dev, test, production] and that dev and test are very similar in configuration while production is quite different.
If I'm using web.config transforms that means I have to duplicate a lot of settings för Web.dev.config and Web.test.config. It would be very nice if I could use the same transform mechanism for my transforms so that test.config is based on dev.config.
I have thought of two possible approaches, i'm not sure any of them would work:
Try to get MSBuild to first transform dev.config and then run test.config against the result when we are running under test configuration
trying to get the transform mechanism to work for transformations files. I would somehow run test.config against dev.config and create a temporary file which I then use as as a transformation against Web.config.
Does anyone know if something like this is possible? And if so how would one go about to set it up?
The TransformXml is just an MSBUILD task that is invoked post compile. If you extend/mod your build you can have it run the transform task twice, or allow the normal run against your configurations, then provide a second file and use the task to perform that.
If you are familiar with msbuild, this is pretty simple. If not, reply/comment, and I'll try to provide examples later today.
But in the end, yes its possible, as I've had similar need on past projects.
I have even more configurations. And all of them synced with T4. See my answer here.
Although this has been answered I wanted to update it with an answer reflecting changes made in Visual Studio 2012 that make this considerably easier.
As of Visual Studio 2012 it is possible to "chain" build and publish profile transforms.
As such you can have a "Release" build transform that takes care of common configuration such as switching off debugging, switching on custom errors, and any number of "Publish" transforms which are associated with a publish profile, adding instance specific data such as connection strings and appSettings.
In VS 2012 (as well as the publishing updates for VS2010 through the
Azure SDK) now support the concept of publish specific transforms. You
can also now specify the project configuration used for a profile when
publishing on the publish dialog...
In this case I have created a profile named Production and set the
Configuration to Release. When I publish this project the following
transformations will be applied (if the files exist) in this order.
1.web.release.config
2.web.production.config
See Profile specific web.config transforms and transform preview for more information.
Do I have to manually edit the Azure connection strings myself to switch between production and development, or is there something comparable to the Transformation Visual Studio applies to Web.Config?
To add to what Brent has said. I use a special small configuration-only (Config) project that contains a folder for every deployment type - inside each folder there is a collection of .config and .cscfg files that are tailored toward a specific deployment (a few partial .config files too). During every compile via Pre-Build event step, Visual Studio copies the files from the correct folder into the root folder of that Config project.
This is the command I use in the Pre-Build Event Command Line:
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.config" "$(ProjectDir)"
xcopy /Y "$(ProjectDir)$(ConfigurationName)\*.cscfg" "$(ProjectDir)"
Every other project in the solution links to the configuration files from the root folder of the Config project.
I also use config transformations as well, for Production vs. Non-production environments. Everything non-Production (local development environment, Azure-QA development environment) has a lot of debug and tracing built in - errors are returned completely to the clients/etc. Production environment has that locked down.
Edit: wrote a blog about this finally: http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx
As Brent pointed out, it is not a good idea to have Staging area to be a full-blown Testing site. It is more geared toward a quick smoke test as well as a great way to deploy a new package into Azure without taking your main site down. (IP swap between Production and Deployment usually does not cause any issues to users)
Hope this helps
First a question, are you referring to configuration settings in the traditional configs? Or in the cloud service config (cscfg)?
If the later, then ATM I'm not aware of any support for configuration transformation. The approach I've seen most folks taking is to maintain number configuration files and use the appropriate file when doing your azure deployment.
This subject also touches on usage of the "Staging" environment. I've seen some folks using it as a parallel testing environment. In practice, its more affective to use it as a staging area to smoke test a new deployment before rolling it into production. If you have a need for a longer term test environment, I've found it better to deploy those services to their own unique namespaces that are then sandboxed away from the production services.
This again touches on ALM best practices for Azure (versioning, deployments, etc..). Something I believe the PNP team is working on and will hopefully have recommendations for soon.
Like knightpfhor said, you can use Visual Studio config transformations if you edit the .ccproj file manually. My answer to a similar question lists the minimum number of steps required to get transformations working.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.
The simple answer to your question is yes, but you have to mess around with the .ccproj file manually to do it. A full description on how to to do this can be found here
I have a web application project that I'd like to be able to branch and develop on a totally separate IIS site and not have to keep editing the vbproj IISUrl setting each time I do it. I have tried adding an import of some standard properties so I can maintain them outside of the WAP file but when I reference them in the element it doesn't like them. I suspect it's because the IISUrl element is part of which is a place to put non msbuild info.
As you can see in the code below, I'm trying to reference $(CustomUrl) in a couple spots in the WebApp1.vbproj but when I open VS it's not liking it.
Any way to resolve this or does anyone have a better way to branch off Web Application projects.
CustomImport.vbproj
<Project
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CustomUrl>http://localhost/WebUrl_1</CustomUrl>
</PropertyGroup>
</Project>
WebApp1.vbproj
<Import Project="CustomImport.vbproj"/>
<WebProjectProperties>
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>1124</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>$(CustomUrl)</IISUrl>
<OverrideIISAppRootUrl>True</OverrideIISAppRootUrl>
<IISAppRootUrl>$(CustomUrl)/</IISAppRootUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>
<CustomServerUrl>$(CustomUrl)</CustomServerUrl>
<SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile>
</WebProjectProperties>
I believe I might have a workaround for this in VS2010.
Right click on the project in VS2010 and go to Properties. In the Web tab, Uncheck the "Apply server settings to all users (store in project file)". What this does is forces all of the settings to be stored in a [Web Project Name].csproj.user file instead of in the project file itself. (Mine is a C# project instead of VB, but I assume it works the same) This allows you to have different server settings on each machine doing development, but at the same time share the rest of the configuration.
I had to do this because I'm using SSL certificates on each development machine (workstation and laptop) so the Project URL is different, but I don't want to have to manually mess with the URL on each machine more than once and worry about it while checking my code into source control.
Once you've done the initial configuration on a machine after getting the latest source, your .user file holds the configuration. So long as you're not checking .user files into source control this seems to work fine.
I've been plagued by the same problem for several years now. The problem persists all the way from Visual Studio .NET (2003) up until now (VS 2010). I have searched for an automated solution for automatic URL renaming but without any success.
What I've been doing to avoid this problem is branching way more and having lots of different workspaces:
Root branch for ongoing project
-> Branch for dev-team
-> Branch for support and long-term code integrity (this is the most commonly used branch by me)
-> My personal custom branches that have different URLs set
I know it's not the best solution but this is the best one that I could figure out.
This article on programmatically changing a project file may be of some use to you in creating a solution to automate the changing of those settings:
Programmatically change Web project settings from dynamic port to static