Does anyone understand Microsoft's idea of TransformXML and running a WebApp with transformed Web.config in Debug mode?!
It's simply so that IIS Express does not pick up transformed (TransformXML in PostBuild) Web.config files from the bin/ folder.
I have tried to copy my transformed Web.config (PostBuild):
Web.config => bin/Web.config
Web.config => bin/<AssemblyName>.dll.config
without success.
I have tried to create temporary files that are imported by "configSource" but they are not copied if not enlisted in the project.
I don't want to have my debug settings as default settings in the project (I'm reusing the transformations for App.config in WebJobs- and Integration tests projects in the same solution).
The proposed solutions of overwriting Web.config in the source folder are just not right.
Simply said: I just want the Web.config to be transformed and take it for a spin by hitting F5. That's it.
Does anyone know how to make IIS Express read the transformed bin/Web.config file when starting a Webapp in debug mode by hiting F5? Anyone knowing of any hidden tweaks for IIS Express to make it work the correct way?
Thanks for any solution on this.
Microsoft would be out of business by the end of the year if developers were able to bill them for all those lost hours of trying to get their non-scriptable non-logical solutions to work in reality.
Related
I've been searching for a long while trying to get this issue solved but so far I've not figured it out. Like David from asp.net config transforms - don't apply for normal builds, only publish, I would like to run a build locally and easily change the database and APIs it connects to with a toggle.
The Solution Configurations with Transforms seems like the best solution but the transforms only get applied when publishing and I can't figure out how to make them apply when doing a local run of the app in IIS Express. I installed SlowCheetah I assumed it'd fix that issue since it does the transforms at compile time but they're still not applied when doing a local build in Visual Studio.
I've also tried using the ConfigurationManager extensions and while they do work for local changes, they're not dynamic. So I can't have a different config based upon the selected Solution Configuration, or a flag in a config file saying "Prod", "Staging", or "DEV".
So how do I make this happen? I'm looking for the following "features":
No secrets checked in to the code repository
Config changes happen even when running the application locally WITHOUT publishing
Being able to debug is important as well.
Changing between local, Dev, Staging, and Prod databases/apis is easy. Best would be the Solution Configuration selection but a single line in a config file specifying the environment and then the system knowing which configs to use from that would be OK as well.
I'm maintaining a webforms application for several different clients in Visual Studio 2008. Each client has their own separate web.config file. We are using config transformation when deploying which works great.
There are many developers currently working on this project, and while developing each developer needs to have the configuration values for a specific client. Right now, what we are doing is that each one of us, has their own version of web.config locally, and we just try to be careful not to check in the web.config file.
This approach of course has several drawbacks. We need to do this manually, which is annoying, we need to be really careful not to check in the config files since it could cause trouble for the rest of the developers, it's cumbersome to add a new value to the config, etc.
I'd like to transform the config files when building from visual studio, so we can chose which file to take the configuration values from, without having to manually edit web.config.
I've been looking in the web for a while, but the best thing i found so far is this:
http://www.codeproject.com/Articles/399002/Project-Build-Web-config-transformation
Which is not working for me, it gives me a build error saying it can't copy Web.config_output because the file is missing.
By default tools like SlowCheetah and other config transform technologies use the $(Configuration) to figure out the name of the transformation to apply. You could take the slowcheetah.targets file and edit it to take $(username) which will pick up the standard windows logged on user name if you're building inside visual studio. You could use a condition to apply the change specifically when '$(BuildingInsideVisualStudio)'='true'.
This will require you to do some work with MsBuild target files, but the end result would be that your developers can check in a web.jesse.houwing.config (in my case) and that of that file is there, their transformation will be applied instead of the standard release or debug transformation.
As for a good starting point, look at SlowCheetah.
Just wondering what is the best option for deploying an ASP.Net Website.At the moment I just place the code in a folder on server and create a virtual directory on IIS referring to this folder. Then I open the website in VS2008 on the server and build it.Though it works fine for me,I am not sure if I am following the best approach for deployment or not.
Thanks.
There's a wealth of opinion on this across the internet and it is all opinion. To an extent it's down to you and your team (if you have one), if your approach is working for you then I don't see any huge reason to change but I would suggest that you at least have a staging site where you can deploy the code for user testing before it's deployed to production.
That said, running VS on the server isn't great (and means you need another VS license so could be a waste) and as VS includes a Publish option anyway, it's rather redundant. I use publish for the smaller sites and it works a fine.
Publish from inside VS is a pretty powerful tool as it lets you do web.config substitution. Check out the Hanselman talk Web Deployment Made Awesome: If You're Using XCopy, You're Doing It Wrong
You have several options which are preferable to running Studio on the server.
Depending on your team size, you could:
publish right from VS
continuous integration, check out Cruise Control for info on that
combination of CI and file synch (i.e. CI to test server then xcopy to production)
I'd advocate for CI since you tend to find issues faster that way, but it assumes you are using good version tracking and testing practices. Copying files can have unintended consequences like missed files, outdated files begin retained, etc.
When you deploy that way, anyone who gains access to the web server (which may be beyond your control if it is hosted) can view and possibly even alter your .aspx pages.
One alternative, which you can use from within Visual Studio, is to compile everything into a binary. You do that by choosing menu Build > Publish > uncheck the checkbox "Allow this precompiled site to be updatable." The downside of this, of course, is that even the tiniest change in a page's HTML will require recompiling the code and redeploying it.
It's a clear tradeoff between security and manageability, but precompilation can also aid in performance. Here is one explanation of precompilation alternatives.
You might also consider the suggestions made in Key Configuration Settings When Deploying a Web Application. In a nutshell,
If you are deploying your web application to a machine that you have control over, such as a web server within your company's intranet or a dedicated web server at a web host provider, you can use the element in machine.config to force all applications on the web server to adhere to the recommendations provided above (namely, using a custom error page, disabling output tracing, and not having the auto-compiled code compiled in debug mode). Simply add the following markup to the machine.config file within the <system.web> element:
<deployment retail="true" />
Again, this is a pretty simple change to make.
On a project I work on, we originally built on a dev machine, zipped and copied the contents of the 'bin' directory across. (unzipping, creating a site in IIS etc...)
Later, when we had the time, we went for this approach:
Creating windows installers in VS2008.
This has worked really well, as (literally) anyone is capable of doing the deployment. The real beauty of this, is that you can account for This is just a fancy way of wrapping the process of copying the 'bin' directory across...
Food for thought I hope.
Dave
I try to run an ASPX page hosted on a Windows Server 2008 x86 through IIS 7.0, with .NET 4.0. I added an application, app1, to the Default Web Site of IIS, mapped to dir C:\toto\app1 which contains the Web.config file.
The error I have is:
Could not load file or assembly 'xxx.dll' or one of its dependencies, etc
and xxx.dll is a .NET DLL that wraps native C++ DLLs (they are the dependencies that fail to be loaded), all of them are located in C:\toto\app1\bin. I tried to modify the PATH env variable so that it contained the bin directory (yes, I know it's bad :-) ), but this did not work anyway.
I guess there should be something at IIS application level, but I could not see what... Could you please help ?
Many thanks !
EDIT: copying the native DLLs in C:\windows\system32 actually works, but it's not a pleasant solution at all...
If its not GACd (which it doesn't appear to be), the simple answer is:
You need the external DLL to be in the bin\ directory of the application.
If you have it as a reference in VS2010, select it, go to properties, and set the CopyLocal value to True. Rebuild the application. This should cause that DLL to copy out to the bin and your app can reference without any other work.
Well, finally managed to make it work by copying the DLLs into windows\system32 directory (no idea why it did not wotk the 1st time, probably an error of mine...). The application\bin folders don't work, neither does the change of the PATH variable.
If anyone knows a better solution (I don't find this one brilliant at all, that can cause DLLs collision and so on), I'd be glad to hear it !
I think this will do the job.
Do this on the server.
Undo all the things you've done before doing this.
Go to START->RUN and type cmd then run the following command regsvr32 "C:\yourfolder\idrskrn_net14.dll" with the " included.
Enjoy!
I have exactly the same problem. The dll are in the webapp/bin directory but aren't loaded. I managed to put them in the inetpub/bin and there it runs fine. However there must be a behaviour that allows loading module in the webapp bin directory. Don't know how to setup this.
I have the same problem. If I browse the website locally on the server it works fine but when I browse it across the internet via the domain name it cannot find the DLL's that are in the bin folder of the site...
I am working with couple of friends on an ASP.NET MVC website. The project is maintained in SVN and I have CC.Net set up to checkout latest version and do automated build and deploy to a pre-production server. The default build configuration is set to Debug, but the automated build is set to build Retail. Everything works just fine, except for the <compilation debug=""> in web.config which currently is set always to true. I'd like to be able to specify true or false for <compilation debug=""> based on the build flavor.
I've thought about two separate solutions to this problem.
I could have a pre/post-build step that modifies the value. However, the web.config file is under source control, so modifying it in the automated build will leave it checked out on the build machine. I could also have additional step that would revert it as well.
I could also instead of having web.config under source control, have a web.config.base file that is used as a source during the build to generate the web.config file. The problem with this approach is that most of the tools modify web.config directly and we have to manually merge such changes back in the base file. And since there's no indication when any tool changed web.config, we have to look for changes at any checkin. Not only this becomes a tedious manual step, but it's also error prone.
Both of these approaches would work, but have some shortcomings. I was hoping there's a more elegant way of doing this. Thus the question - how do you guys deal with modifying web.config that is under source control during the CI builds?
You can take a look at the Web Deployment Projects VS add-in. Scott Guthrie does a great job explaining it in this post.
Why not modify web.config as part of a build-step using a command line utility that can edit XML?
e.g. Obtain a command line utility that works like:
xml_mod.exe web.config [xpath-of-value-to-change] [new-value]
Then have different value per debug/release(retail)..
Why don't you just make the web.config read/write without checking it out from source control, make your changes you need during the build process and then discard them?
AFAIK SVN has the files read/write anyway.
we have a
web.config for development
web.config.cert which is deployed by hudson to our cert environment
web.config.prod which is used for production
This allows us to put comments in there and values in there specific to the environments when that would normally have to go in some documentation somewhere, and it would surely be ignored.
Like I said, we have Hudson deploy to our cert environment on each build, so it just copies the directory over, deletes the web.config and renames web.config.cert to web.config
You may want to check out Hudson, I dont think I've ever heard of anyone choosing CC.net over Hudson if they had the ability to choose :)