Comments (20)
Thanks for the reply Davi..
I must say that this kind of sucks that it doesn't do it for web apps because it would be so super helpful to be able pick a configuration and start debugging with those configuration settings...are there any plans to make it work as such?
..It does perform correctly on publish. Would you recommend (and I will research it) of the best approach to make it work like I want it to?
Thanks again.
from slow-cheetah.
I also think it would be ideal to have an opt-in behavior that comes with SlowCheetah for transforming the base Web.Base.Config to Web.Debug.Config / Web.Release.Config / Web.SomeCustomConfig.Config based on whatever's selected when one hits F5. Everything would 'derive' from Web.Base.Config by default, and then transform accordingly.
This would also be such a great time saver and reduce inter-config copy/paste errors during the process of debugging different configurations. This sounds like a perfect solution to me:)
from slow-cheetah.
Here's what we do. It's not hard to set up but not intuitive or well documented.
- Create web.config.template. No build action, do not copy. Copy-paste your web.config contents here. (This is an arbitrary name, no black magic.)
- Right-click and select "Add Transform". This will get you files like Web.config.Debug.template and Web.config.Release.template. Add your transforms here.
- Unload your project (right-click on project, select "Unload Project")
- Open the .csproj file (right-click on closed project, select "Edit .csproj"
- Add the XML below to the bottom of the file (just before )
- Build the project. This should create a web.config file, but you still need to add it to the project.
- Click "Show All Files"
- Right-click the new web.config that was created and select "Include in Project"
- Delete and transform files that were added automatically under web.config
<Target Name="BeforeBuild">
<TransformXml Source="Web.config.template" Destination="Web.config" Transform="Web.config.$(Configuration).template" />
</Target>
Now when you build, you'll get a shiny new web.config that is the result of the transformation.
Be sure to add the .template files to source control, and exclude the actual web.config. I also put a big warning at the top of Web.config.template to only edit the .template files, not the actual web.config, or your changes will be overwritten.
from slow-cheetah.
@Laperuta this doesn't work for me, the transformation is still not applied
from slow-cheetah.
Yeah. I don't understand why Microsoft didn't simply allow you to write a Web.config in the bin directory that would override the main Web.config file. Then you could apply your XSLT transformations to that before debugging, and it would solve a lot of problems.
from slow-cheetah.
Another workaround for transforming Web.config files for debugging purposes is doing this.
<TransformXml Source="Web.config" Destination="$(OutputPath)\Web.config" Transform="Web.$(Configuration).config" />
(Note that this creates a new Web.config file in your bin folder. This doesn't use the ProjectName.dll.config file that already exists in your bin folder.)
And do this in your Application_Start
:
var transformed = WebConfigurationManager.OpenWebConfiguration("~/bin"); // this will read the new Web.config
foreach (KeyValueConfigurationElement setting in transformed.AppSettings.Settings)
{
WebConfigurationManager.AppSettings.Set(setting.Key, setting.Value);
}
This method avoids the drawbacks of the Web.Base.config method. But it has it's own issues. You can't use xdt:Transform(Remove)
. You also can't use anything other than app settings in your transformation (so no connection strings).
from slow-cheetah.
A major drawback of the Web.Base.config / template approach is that often when installing NuGet packages, changes are applied to the Web.config file, and not to the Web.Base.config file. Build once and these changes are now gone, you probably never even noticed a NuGet package tried to add them. And then you wonder why something doesn't work.
Agreed, and it's bitten me before. I've soured on this approach, and now just try and avoid getting too tricky with web.config transforms. I'll usually have the dev connection strings in the main file and use the Release template for prod settings, which only get applied when I publish the site. If I need to test against prod I manually tweak the connection strings while testing.
from slow-cheetah.
Microsoft wants to sell Azure Key Vault, that's why they don't allow simple local specific configurations like any other frameworks provide.
from slow-cheetah.
The transformation does indeed get applied to the config file (you can verify this by looking at the web.config file in the output folder). Unfortunately, web projects don't use the configuration file in the output folder, it uses the in-place web.config (the original one in your project tree). This is different from other project types that use the app.config on the output folder.
Since the SlowCheetah transformation process does not alter project files itself (only output files), transformations won't work on F5 for web projects, only on publish.
from slow-cheetah.
It's a little more complicated for web projects since they already start off with a base file and transformation files. XML transformations already exist for these projects on publish. Transforming the original file on build would result in changes for users that already use it as their base config.
One option that is available is to have Web.Base.config
as the base configuration and then have Web.{Configuration}.config
as the transformation files. Then, on F5, the transformation output would override Web.config
in the project folder.
If you have knowledge of MSBuild targets, you can attempt to do this by altering the ScAppConfigName
property to Web.Base.config
(don't forget to create transforms for this file, i.e Web.Base.{Configuration}.Debug
) and then creating a target to copy the transformed Web.Base.Config
file in the output to the original location of web.config
.
As for including this behavior (with Web.Base.Config) in SlowCheetah, what would you think of it being an opt-in behavior that is turned off by default? This would be ideal so no one's experience is changed unless they want to.
from slow-cheetah.
I am not sure if we want to support this behavior officially in slow-cheetah. It is only a partial solution and introduces other issues such as #64
from slow-cheetah.
@jviau I just had same issue as @WebDev64.
I understand that described above behavior is working for web based projects and default and there isn't way to change it right now.
I'd like to create issue with proposal of changing this behavior, but I'm unsure where I should create it. Is it VS or IIS Express related issue?
I think it's reasonable to have same behavior for all types of projects. Don't You agree?
from slow-cheetah.
@nlaslett Unfortunately I think that solution would fail if you're publishing the website through Visual Studio Team Services. There's a build step that goes through all the files referenced in Solution Explorer before the build and if any of them are not on the file system it crashes out with a "file not found" error. Very annoying but there you are.
from slow-cheetah.
I solved this simply adding this to the .csproj file:
<Target Name="BeforeBuild"> <TransformXml Source="Web.config" Destination="$(OutputPath)\Web.config" Transform="Web.$(Configuration).config" /> </Target>
Hope it helps.
from slow-cheetah.
A major drawback of the Web.Base.config / template approach is that often when installing NuGet packages, changes are applied to the Web.config file, and not to the Web.Base.config file. Build once and these changes are now gone, you probably never even noticed a NuGet package tried to add them. And then you wonder why something doesn't work.
from slow-cheetah.
@jez9999 I was just thinking the same thing. This difference between web projects and regular applications is exactly why SlowCheetah doesn't work for web projects, it relies on having an "output config" in the bin folder.
I solved this simply adding this to the .csproj file:
<Target Name="BeforeBuild"> <TransformXml Source="Web.config" Destination="$(OutputPath)\Web.config" Transform="Web.$(Configuration).config" /> </Target>
You are replacing the Web.config itself with a new Web.config. Doing this, you won't be able to properly use Insert
in your transformations. If you do, you'll run in to issues after transforming twice, because now your Insert
happened twice. Also, this is not a suitable approach if you want to put developer-specific or sensitive data in a separate (non-committed) transformation.
Never mind, I missed that $(OutputPath)
in there... this won't work. See my suggestions below.
from slow-cheetah.
@RudeySH I just posted an issue about it: https://github.com/aspnet/KestrelHttpServer/issues/3038
from slow-cheetah.
Why would transforms kill off changes made to the base web config? You don't have to replace all appSettings, for instance - you can just match the ones you want to modify and replace them.
from slow-cheetah.
Why would transforms kill off changes made to the base web config? You don't have to replace all appSettings, for instance - you can just match the ones you want to modify and replace them.
The problem on a web project is your web.config is in the project root, not the bin folder. When you Publish it's not an issue: the transformed file becomes the new web.config in the publishing root. But when you just debug in place (F5), your original web.config (without the transformations) is what you're running on. (You do get the transformed file in the bin folder as {project}.dll.config, but that doesn't help any.)
My initial idea (which works) was to instead have a web.config.template file with build-specific transforms under that. Then, when you build (not publish) you generate a crisp new web.config in the web root. Change from Release to Debug? You get a new web.config with the right settings. Great, eh?
The problem is, as @RudeySH points out, is that some NuGET packages need to add or update entries in the web.config. So they do that, but they're updating the generated file, not the web.config.template. Then when you rebuild, you lose those changes. It's a real pain if you forget to manually copy those changes over (or don't notice).
I take back my original advice. Instead, make your base web.config with all your debug settings, and use the release transform file for production. Then, publish the project when you go to prod. (Yes, I've seen people "deploy" web projects by copying the project root...)
from slow-cheetah.
Just start it from the debugger folder and attach to process. It will load the transformed configuration and you will be able to debug it.
from slow-cheetah.
Related Issues (20)
- This repo is missing important files
- Use INuGetProjectService instead of IVsPackageInstallerServices
- SlowCheetah no longer working in VS2019 HOT 1
- Transformation Damages Values with ">" in Them HOT 2
- Problem with readonly app.config files
- ClickOnce not coping data files after Transform
- The transformation is correctly applied and the resulting config file in the output looks as expected. But the configuration loaded in memory is as if taken from the original config file. project is .net framework 4.7.2 self-hosted winform app using appsettings.config file
- How to json arrays of objects or attributes therein HOT 4
- VS2022 Error while loading solution HOT 16
- Transform Not Working In Template Studio Created WinUI 3 Projet
- Old NuGet project page still accessible and getting downloads HOT 1
- TransformXml task could not be loaded from the assembly HOT 1
- SlowCheetah 'File not found' issue when publishing to the file system using msbuild HOT 1
- Per-user transformations HOT 1
- App.config Transform not working with VS2022 HOT 3
- Transform fails when project is targetting multiple frameworks HOT 2
- Publish WPF Core App with ClickOnce does not transform App.Config
- Q: How to publish transformed file to multiple directories HOT 2
- Q: How to coordinate internal targets with SC processes HOT 1
- Can't install VSIX for VS 2022 Enterprise edition HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from slow-cheetah.