XML file replacement program? (web.config/WDP related)
I've been running into alot of limitations with the web.config replacement code in VS 2008's Web Deployment Project. Some of these seem to be:
So thinking instead that it would be easier to simply write my own replacement program, which is "dumber", but without these limitations. So before setting off, I wonder if there's something else out there which:
Or am I doing something totally wrong here? The WDP's config replacement code just seems fairly useless (and hard to find documentation for).
In my experience, it has just been easier for me to have three files in my project, say, Web-Release.config , Web-Debug.config , and Web.config , and then I modify the project file (which is just an MSBuild script) to copy the contents of either the -Debug or -Release file over the Web.config during the build process. Happily, this type of behavior is apparently built into Visual Studio 2010, but for the present day it's pretty easy to add by just right-clicking your project file, unloading it, and then editing the file to do the switcheroo:
<Target Name="AfterBuild">
<Copy SourceFiles="Web-Debug.config" DestinationFiles="Web.config" ContinueOnError="false" Condition="'$(Configuration)' == 'Debug'" />
<Copy SourceFiles="Web-Release.config" DestinationFiles="Web.config" ContinueOnError="false" Condition="'$(Configuration)' == 'Release'" />
</Target>
Another option I have used in the past was to build an MSBuild task for this XML file merger. It was useful for generating App.config files that were shared for a server that had a Windows console application host (for debugging) and a Windows Service host (for production): most of the common settings lived in an App.config in the shared project, and each host project had an App.config that defined additional settings, and then I'd edit each host project's MSBuild project to run my custom task to merge the two App.config s into one big App.config . But that was probably overkill.
I think it's easier to just create a .config file for each of your deployment scenarios as described above. If there's lots of stuff in common, using the configSource attribute on elements can cut down on the duplication.
Hope that helps to address the nature of your problem, though it probably wasn't exactly what you were looking for.
disclaimer: I'm going to spam you by talking about my program I've written to do this
I've written something to do this: dashy. It's slightly involved to set up (maybe, depends on your environment), but it is designed to solve exactly the problem you have - managing your configs for different environments (and additionally, the deployment thereof).
Alternatively, pre-dashy, I just used nant tasks with specific .properties for each environment, and execute the relevant one, post build.
链接地址: http://www.djcxy.com/p/42584.html上一篇: 相当于c＃中#region的Java