Tuesday, December 21, 2010
File Lock Problem in Visual Studio 2010 Build
Unable to copy file "obj\Debug\MyProject.dll" to "bin\MyProject.dll". The process cannot access the file 'bin\MyProject.dll' because it is being used by another process.
For the first couple of days, I just grumbled angrily to myself and restarted Visual Studio whenever this happened, which it did not do consistently. Sometimes it would work correctly for dozens of build/debug sessions, only to pop up at random times seemingly chosen to maximize my irritation.
Anyway, I did some searching around, and this is a fairly common complaint, with a fairly simple workaround. I actually saw several different approaches to this, but the most elegant was the one I found here. His sample assumes you are writing Visual Studio add-ins, but his fix works for Web Site projects, and should work for other project types as well. I won't go through explaining the details of this problem, as the post linked above does a good job of that, but I will provide the fix here. Simply add the following lines of code to the pre-build event command line of your project (the linked post provides a screenshot of what this look like in Visual Studio):
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Thursday, February 18, 2010
ASP.NET 4 Web.config Transformations
The web.config file in ASP.NET is a good thing. Among other things, it gives us a consolidated place to store configuration settings and connections strings, providing a single place to maintain these settings. That way, when it's time to migrate our awesome code from development to a test/staging/production environment, we can go into the web.config and change the appropriate settings and away we go. If you're anything like me, your web.config files have groups of settings that are commented out, allowing me to do some simple copy/paste when I'm ready to change settings for a different environment. But, what if we could just create multiple configurations, and have the appropriate ones get used, based on Visual Studio build configurations? What if switching from Debug to Release was all it took to swap in all of the relevant appSettings, connectionStrings, or whatever else needs to be changed? Well, ASP.NET 4 provides this in the form of web.config transformations.
By default, when you create a new Web Application project in Visual Studio 2010 (from what I can tell so far, Web Site projects do not provide this functionality, only Web Application projects), you automatically get a Web.config, and also two new items, Web.Debug.config and Web.Release.config, which correspond to the two default build configurations (Debug and Release). By using transformations, we can provide config-specific changes that get applied to the web.config at build time. There is an MSDN article that goes over the transforms at a high level, which can be found here. There is a great deal of flexibility, allowing you a great deal of control over how the actual web.config file gets built. Here, I'll provide a specific example, one that we all deal with regularly. Let's say we have different database connection strings for Debug (development) vs. Release (production). Below are contents from a sample web.config, web.debug.config, and web.release.config that would make this automatic.
Web.config:
Web.Debug.config:
Web.Release.config:
In my next post, I'll expand on this and show how to very easily tweak this to create configurations for development, staging, and production environments.
Friday, March 13, 2009
Browse with Firefox, Debug with Internet Explorer
NOTE: I originally published this entry on my company blog here.
As a .NET developer, it is a necessity to debug my work in Internet Explorer. However, for my day-to-day web borwsing, I prefer to use "something else". Lately, my something else has been Google Chrome, but I'm also a big fan of Firefox. The problem is that, by default, if I change my default to be Chrome, then when you hit F5 to debug in Visual Studio, then Chrome is what gets launched for the debugging sessions. For basic stuff, this is fine, but it's not ideal for me, particularly when I want to be able to debug client-side script from within Visual Studio.
I have dealing with this for a long time basically by not dealing with it at all... That is, I have left Internet Explorer as my defaut browser and just launched Chrome for my routine browsing. This is OK, but then whenever there is a link in an email, or a blog post (I use Outlook for RSS feeds), then Internet Explorer gets launched to handle it. Not what I want.
Well, I finally got irritated enough by it this morning to hit Google and see what I could find. It turns out the answer is pretty simple, but differs a little bit depending on whether the project is a Web Site project or a Web Application project.
Web Application Project
In Visual Studio, if you go right click on the project in the Solution Explorer, and go to Project Properties, the on the Web tab you can configure a custom Start Action, rather than just launching using the default browser. Under Start Action, you would select "Start External Program", and use "C:\Program Files\Internet Explorer\iexplore.exe" to launch Internet Explorer. Then, for "Command Line Arguments", you have to supply the URL of the start page. In my example, this is "http://localhost:60669/Default.aspx". The port number is required because I have also elected to use the Visual Studio Development Server, which can be seen in the next section, "Server". The only thing that has to be changed there is that instead of allowing Visual Studio to randomly assign a port number, you must pick one.
Here is a screenshot of some example settings that work for a project of mine.
