Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 175 Vote(s) - 3.57 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Use Visual Studio web.config transform for debugging

#1
> **Possible Duplicate:**
> [How can I use Web.debug.config in the built-in visual studio debugger server?](

[To see links please register here]

)

<!-- End of automatically inserted text -->

I want to use the Web.config transformation that works fine for publish also for debugging.

When I publish a web app, Visual Studio automatically transforms the `Web.config` based on my current build configuration.
How can I tell Visual Studio to do the same when I start debugging?
On debug start it simply uses the default `Web.config` without transformation.

Any ideaa?

Reply

#2
In your debug configuration, add a post-build step, and use it to replace/transform your `web.config`
Reply

#3
You could just use the 'default' web.config as your development/debugging version, and then the web.release.config would of course continue to be the release version, since its transforms are applied when you publish.
Reply

#4
Andrew is on the right path. When you are using this feature here is how it was designed to be used.

**web.config**
This is the config file which developers should use locally. Ideally you should get this to be standardized. For instance you could use localhost for DB strings, and what not. You should strive for this to work on dev machines without changes.

**web.debug.config**
This is the transform that is applied when you publish your application to the development staging environment. This would make changes to the web.config which are required for the target environment.

**web.release.config**
This is the transform that is applied when you publish your application to the "production" environment. Obviously you'll have to be careful with passwords depending on your application/team.

The problem with transforming the web.config that you are currently running is that a transform can perform destructive actions to the web.config. For example it may delete a attributes, delete elements, etc.



Reply

#5
Although I agree that the simplest approach is usually the best, I can easily imagine a circumstance where for some period of time you want to connect your IDE to a test database instead of your development database. Although you can specify the development connect strings in your default web.config file, it would be really nice to have a Web.Test.config file so that when you swap your build configuration to "Test", you would automatically get the new settings while still in your IDE.

The historical alternative is commenting out one set of connection strings for another, but these new config transforms held out the hope of finally putting a stake in the heart of that ugly practice. Although one default file for development and a transform for release may work much of the time, adding a post-build step to transform the web.config file is the more complete answer in my opinion.
Reply

#6
OK, with the understanding that `web.debug.config` & `web.release.config` are for package/publish only. I have come up with a way in which to enable what you are trying to do. I've blogged about it at [

[To see links please register here]

][1].
Here is the summary.

Now let’s see how we can enable what the question asker wants to do.

To recap, when he builds on a particular configuration he wants a specific transform to be applied to `web.config`. So obviously you do not want to maintain a `web.config` file, because it is going to be overwritten.

So what we need to do is to create a new file `web.template.config`, which is just a copy of `web.config`. Then just delete `web.config` by using Windows Explorer (don’t delete using Visual Studio because we do not want to delete it from the project).

**Note: If you are using a source control provider which is integrated into Visual Studio then you probably want to delete web.config from source control.**

Also with this we do not want to use `web.debug.config` or `web.release.config` because these already have a well defined role in the Web Publishing Pipeline so we do not want to disturb that. So instead we will create two new files, in the same folder as the project and `web.template.config`, `web.dev.debug.config` and `web.dev.release.config`.

The idea is that these will be the transforms applied when you debug, or run, your application from Visual Studio. Now we need to hook into the build/package/publish process to get this all wired up. With Web Application Projects (WAP) there is an extensibility point that you can create a project file in the same folder with the name `{ProjectName}.wpp.targets` where `{ProjectName}` is the name of the project. If this file is on disk in the same folder as the WAP then it will automatically be imported into the project file. So I have created this file. And I have placed the following content:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- Make sure web.config will be there even for package/publish -->
<Target Name="CopyWebTemplateConfig" BeforeTargets="Build">
<Copy SourceFiles="web.template.config"
DestinationFiles="web.config"/>
</Target>

<PropertyGroup>
<PrepareForRunDependsOn>
$(PrepareForRunDependsOn);
UpdateWebConfigBeforeRun;
</PrepareForRunDependsOn>
</PropertyGroup>

<!-- This target will run right before you run your app in Visual Studio -->
<Target Name="UpdateWebConfigBeforeRun">
<Message Text="Configuration: $(Configuration): web.dev.$(Configuration).config"/>
<TransformXml Source="web.template.config"
Transform="web.dev.$(Configuration).config"
Destination="web.config" />
</Target>

<!-- Exclude the config template files from the created package -->
<Target Name="ExcludeCustomConfigTransformFiles" BeforeTargets="ExcludeFilesFromPackage">
<ItemGroup>
<ExcludeFromPackageFiles Include="web.template.config;web.dev.*.config"/>
</ItemGroup>
<Message Text="ExcludeFromPackageFiles: @(ExcludeFromPackageFiles)" Importance="high"/>
</Target>
</Project>

Let me explain this a bit. I have created the CopyWebTemplateConfig target which will always copy `web.template.config` to `web.config` on build, even if you are not debugging your application in Visual Studio.

This is needed because we still need to support the package/publish process of Visual Studio. Then I extended the property `PrepareForRunDependsOn` to include the `UpdateWebConfigBeforeRun` target. This property is used to identify the list of targets which needs to be executed before any managed project is run from Visual Studio.

In this target I am using the `TransformXml` task to transform `web.template.config`, using the correct `web.dev.***.config` file. After that your app starts up using the correct `web.config` based on your build configuration.
After that I have another target `ExcludeCustomConfigTransformsFiles`, which I inject into the package/publish process via the attribute `BeforeTargets=”ExcludeFilesFromPackage”`. This is needed because we do not want these files to be included when the application is packaged or published.
So that is really all there is to it.

To explain the package/publish process a bit more for this scenario. When you package/publish `web.debug.config` or `web.release.config`, depending on build configuration, will still be used. But ultimately the file that it is transforming is `web.template.config`, so you may have to adjust depending on what you have in that file. Questions/Comments?

[1]:

[To see links please register here]

Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through