First of all, we're not using the Web Application project, we're using the Web Site type of project.
In our project we have 3 build configurations, which are: Dev (for development), Demo (for testing) and Live (final release of course).
We have two files (but in the end it'll be 4) which are:
Web.config
Web.Dev.config
A snippet from the first:
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<add name="SomeConnectionString" connectionString="oldConnStr" providerName="System.Data.SqlClient"/>
</connectionStrings>
<system.web>
<compilation targetFramework="4.0" debug="false">
<assemblies>
<add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
</assemblies>
</compilation>
</system.web>
</configuration>
And this is the transformation:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="SomeConnectionString" connectionString="newConnString" providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" />
</connectionStrings>
<system.web>
<compilation debug="true" xdt:Transform="SetAttributes(debug)" />
</system.web>
</configuration>
It doesn'work at all, neither does the Web.config become 'expandable', screenshot:
The icons are from Team Foundation Server
Does anyone know how to make this work?
I found out this can't be done in a Web Site project. It requires a .csproj file, and Web Site's don't have that.
You need a configuration instance to match your web.config transformations. For example, in order for Web.Dev.config to compile and transform (during a web deploy etc.) you need to compile the project in the 'Dev' configuration.
If you don't have a Dev configuration defined (by default you usually get a Debug and Release configuration when starting a new VS project) you can click the drop-down box with all the available configurations listed. You can usually find this next to the green 'play' (start debugging) button in Visual Studio. Select the 'Configuration Manager ' option and then for your selected project, select the configuration drop down and select . You can then create a configuration called Dev (and copy the settings from an existing configuration if you need to). Be sure to refresh your project tree once this is done.
It's also worth noting that trasnformations are not applied during standard in VS builds (i.e Ctrl+Shift+B) builds. These usually applied when the application is released via Web Deploy or a deployment tool of some kind. The transformation applied will depend on the selected build configuration. I.e. deploy in 'Dev' configuration and your web.dev.config transformations will be applied.
Related
In my windows service I have 2 web references
My windows service only contains an app.config not a web.config
my app config looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="MyFirstWindowsService.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
</startup>
<system.serviceModel>
<bindings />
<client />
</system.serviceModel>
<applicationSettings>
<MyFirstWindowsService.Properties.Settings>
<setting name="MyFirstWindowsService_postDataToMapicsWC_XAXSSTRN"
serializeAs="String">
<value>http://TESTDEV/web/services/XAXSSTRN.XAXSSTRNHttpSoap11Endpoint/</value>
</setting>
<setting name="MyFirstWindowsService_com_goodmanmfg_testdev_GETITMINFO"
serializeAs="String">
<value>http://TESTDEV/web/services/GETITMINFO.GETITMINFOHttpSoap11Endpoint/</value>
</setting>
</MyFirstWindowsService.Properties.Settings>
</applicationSettings>
</configuration>
[![enter image description here][1]][1]
the problem is my web services when i click on them the URL field is still saying
"Web reference URL" http://PROD/web/services/XAXSSTRN.XAXSSTRNHttpSoap11Endpoint
[![enter image description here][2]][2]
what is the end goal? To release this windows service to dev and prod environments without having to rebuild the entire solution.
The ideal behavior is :
Build the latest code in dev mode (test it, if all test good then , step 2)
Provide an app.config file with prod urls to dropped inside the
folder
Release
As you can see what I am trying to avoid is the need of dropping the file manually changing those 2 web services , rebuilding the solution AND THEN releasing...
Classic ASP.NET apps get their configuration from a hierarchy of web.config values. Other apps (console applications, Windows Forms apps, WPF, Services, ...) get their configuration from a configuration file named [NameOfExe].exe.config (and occasionally from [NameOfAssembly].dll.config. That file is located in the same folder as the exe itself.
For example, if your service is MyWcfService.exe, you will very likely find a MyWcfService.exe.config file in the same folder (for example, in the bin/debug folder). Its contents should be the same as your app.config.
Visual Studio makes this all "just work" by creating an app.config file in your source folder and then, at build time, copying the contents of that file to the appropriately named [NameOfExe].exe.config file in the same folder as the EXE.
In the normal case, you might have one set of URLs (and perhaps other data) for your dev environment, another for QA, another for Integration Test and another for Prod. You can manage this through the use of configuration transforms.
I think this goes some way towards answering your questions. In summary
App.config files have nearly the same capabilities as web.config
files
App.config files get "compiled" to [NameOfExe].exe.config
files at build time and placed in the same folder at the EXE
Configuration transforms may help you out with managing your URLs
Your other choice is managing a set of [NameOfExe].exe.[Environment].config files and manually putting them in the right place.
I have had to add a monoSettings section to my Web.config file as I need to support colons in the url (similar to this question: ASP.NET special characters in URL (colon) not working even with requestPathInvalidCharacters="").
Now when I run my web-api service in visual studio (which I do for ad-hoc testing) it gives an error:
"The configuration section 'monoSettings' cannot be read because it is missing a section declaration"
I'm just wondering what is the best way to support this config in my Mono service without impacting being able to run in on Windows? Can I just flag it as optional or unimportant so that it won't fail when trying to read the config? Or is it just better to have a different build configuration for Mono - but I'd then have to maintain two versions of web.config with just this one minor difference.
I resolved this issue by adding a configSection to my Web.config as follows:
<configuration>
<configSections>
<sectionGroup name="system.web">
<section name="monoSettings" type="DataSetSectionHandler,SectionHandlers" />
</sectionGroup>
</configSections>
<system.web>
<monoSettings verificationCompatibility="1" />
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,\,?" />
</system.web>
</configuration>
As it stands, right now when I deploy my web application I always go into my web.config file to change the server name etc from the connection string manually before deploying the application. Is there an easier way to deploy a web app without having to always change the server in the connection string?
Thanks
Use a transform Web.config When Deploying a Web Application Project:
How to: Transform Web.config When Deploying a Web Application Project
Web.config Transformation Syntax for Web Project Deployment Using Visual Studio
It depends on how you are deploying your web app, but one common way to do it is to use web.config transforms
http://msdn.microsoft.com/en-us/library/dd465326%28v=vs.110%29.aspx
we use WIX installer exactly for this purpose.
It can be customized, like in my case, to select DEV, QA or PROD env while installation.
Best thing is it uses underlying MSI installation framework, if thats the right word here.
Assuming you only need to change the connection string for just one specific Web Deploy then you can do that with a transformation as others have said. The following should show exactly what you need to do.
In Solution Explorer expand the Properties node to get the PublishProperties as in the following.
Right-click on the Web Deploy profile and select Add Config Transform as shown in the following.
You will get a Web.project - Web Deploy.config file in the Web Config node. The initial contents will be the following.
<?xml version="1.0" encoding="utf-8"?>
<!-- For more information on using web.config transformation visit https://go.microsoft.com/fwlink/?LinkId=125889 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<!--
In the example below, the "SetAttributes" transform will change the value of
"connectionString" to use "ReleaseSQLServer" only when the "Match" locator
finds an attribute "name" that has a value of "MyDB".
<connectionStrings>
<add name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
-->
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<!--
In the example below, the "Replace" transform will replace the entire
<customErrors> section of your web.config file.
Note that because there is only one customErrors section under the
<system.web> node, there is no need to use the "xdt:Locator" attribute.
<customErrors defaultRedirect="GenericError.htm"
mode="RemoteOnly" xdt:Transform="Replace">
<error statusCode="500" redirect="InternalError.htm"/>
</customErrors>
-->
</system.web>
Change the sample to the following or add the following.
<connectionStrings>
<add name="csname"
connectionString="yourotherconnectionstring"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
Where csname is the name in the Web.config of your connection string that you need to replace in the deployment.
There are many other transformations possible but if you only need to change the connection string for a specific Web Deploy then that should be the most straight forward. It is saying that you want to search for the connection string that has the specified name and then change the connection string value during the deployment.
I'm using this code (in my DAL project):
ConfigurationManager.AppSettings["server"]
to access appsettings section in web.config file (from web project):
<appSettings>
<add key="server" value="server.name.com"/>
<add key="database" value="databasename"/>
</appSettings>
and in a Web.Debug.config I'm using a following transformation
<add key="server" value="MY-LAPTOP"
xdt:Locator="Match(key)" xdt:Transform="Replace"/>
after that when I start application the config file isn't transformed. First line of code returns the nontransformed infromation. What's wrong with the code? What am i missing?
I have tried to publish it and when I check config file everything is ok like it is ment to be.
The web.config transformation is only perform during the publish process. You can still enable it on every build, when you it F5, see
ASP.NET Web Projects: web.debug.config & web.release.config
SlowCheetah - XML Transforms
Making Visual Studio 2010 Web.config Transformations Apply on Every Build
It's an MSBuild task to add.
While uploading my current project to our staging server I noticed that the Web.config file of my Asp.net MVC framework contains some references to assemblies called
Hostadapters.AspNetAdapter
QualityTools.Common
QualityTools.ExecutionCommon
QualityTools.Resource
I have not added the entries myself, but guessing from their names, I suspect these have been added by the "Add Unit Tests" Wizard.
The problem is, with these assemblies being referenced, the project does not run on my staging server, because it can't find the relevant DLLs. Their paths are hard-coded into the
Web.config:
<httpModules>
<add name="HostAdapter" type="Microsoft.VisualStudio.TestTools.HostAdapter.Web.HttpModule, Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</httpModules>
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<codeBase version="10.0.0.0" href="file:///C:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio%2010.0/Common7/IDE/PrivateAssemblies/Microsoft.VisualStudio.QualityTools.HostAdapters.ASPNETAdapter.DLL" />
</dependentAssembly>
Am I correct in thinking that these assemblies are Unit-Testing-Related?
When I tried to remove some of these entries, the server responded with an error 403 "Access Denied: Forbidden." What might be the meaning of this, and how can I avoid it?
I could simply upload the referenced DLL files somewhere onto the server, but that seems counter-intuitive. Do I have other options?
Edit: I have read the suggestion to split configuration into separate parts. It is a good suggestion, but it doesn't help me with my immediate problem of how the heck do I get any configuration working on the server?
Pain that the testing mauls your config and breaks your deployment, happened to me, too. Proper way to solve it is to use different config files for Debug, Staging and Release.
This explains what they do and points to more information.
What are the Web.Debug.config and Web.Release.Config files for?
Here are the transforms for removing the offending modules:
<system.web>
<httpModules>
<add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove" />
</httpModules>
</system.web>
<system.webServer>
<modules>
<add name="HostAdapter" xdt:Locator="Match(name)" xdt:Transform="Remove"/>
</modules>
</system.webServer>
I would have separate web.config files for staging and live regardless.
There are frequently many settings which need changing for development purposes, e.g. Cache lengths, security settings, urls etc.
From my experience, using the same config is a recipe for disaster - it takes 1 developer to change the settings to get something working locally, and then check the updated file in, and you end up with a broken staging server (or possibly live)!
If you use a build then it is simple to substitute web.config with web.live.config or web.staging.config during the build process.
Your problem then goes away.