Showing posts with label web development. Show all posts
Showing posts with label web development. Show all posts

Tuesday, December 21, 2010

File Lock Problem in Visual Studio 2010 Build

I have been banging my head against my padded cubicle wall for several days now in frustration over a build error that keeps popping up in Visual Studio 2010.  When attempting to debug, or even just build without launching the debugger, I keep getting an error that looks like this:

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

NOTE:  I am running Visual Studio 2010 Beta 2 Ultimate Edition, so any references to or images of Visual Studio 2010 are from that version.

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.



Web Site Project

If the project in question was created as a Web Site Project, then the configuration is slightly different.  First, click on the project in the Solution Explorer, and the in the Properties pane, change the Use Dynamic Ports property to False.  This will enable editing of the Port number property.  Set the port number to some fairly high numberl I used 60668 in my example.  Make note of what is in the Virtual path property, because you will need it for the next step.  (You can also change this virtual path if you wish).

Next, right-click on the project in the Solution Explorer and select Property Pages.  Under "Start Options", choose "Start External Program:"  The executable (C:\Program Files\Internet Explorer\iexplore.exe) and command-line arguments (http://localhost:60668/Website1/Default.aspx) arethe same as for Web Application projects.   The command-line arguments need to use the port number and Virtual path from the previous step.

Here are a couple of screenshots that work for my sample project.