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"
Showing posts with label visual studio 2010. Show all posts
Showing posts with label visual studio 2010. Show all posts
Tuesday, December 21, 2010
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.
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.
Monday, February 15, 2010
Visual Studio 2010 Has Database Comparison Tools!
Once of the common pain points for me as a developer is deploying database changes from my development environment (generally my laptop) out to a test/staging server. It's not always a great idea to just blow away the test/staging database and replace it with my local copy, as there may be other things in place that I don't want to get rid of. Besides, there are usually differences between the security/user configurations on my local machine as compared to my test/staging servers.
This is where database comparison tools come into play, giving developers the ability compare two databases and generate scripts to update one or the other. I have been a long-time user of one such tool, but I have always disliked the fact that Microsoft has never provided this sort of functionality from directly within their database tools. As far back as Query Analyzer in SQL 2000, it seemed like there should be a diff tool built in. Especially once we went to SQL 2005, and Management Studio got an interface that more closely tied into Visual Studio, it felt like a database diff tool was a pretty glaring omission.
Microsoft has rectified this problem in Visual Studio 2010, providing what appears to me to be an extremely capable comparison tool that allows for schema and data comparisons, at least in the Ultimate Edition. This morning, I used the new schema comparison tool to script and deploy changes to a test server for a project I am working on. I'm not going to go into any detail here about how tool works or how to use it, as the point of this post is simply to say that I am really stoked about the new tool and especially how nicely integrated the whole thing is into Visual Studio.
As I get a chance to use these tools more, I'll put together a few posts on how to use this new functionality.
UPDATE: As I dug into this more, I learned that Visual Studio 2005 and 2008 also had the schema and data comparison tools, but were only present in the Database Edition and Team Suite, neither of which I was running. I'm not 100% sure how the various editions are going to break down for 2010.
This is where database comparison tools come into play, giving developers the ability compare two databases and generate scripts to update one or the other. I have been a long-time user of one such tool, but I have always disliked the fact that Microsoft has never provided this sort of functionality from directly within their database tools. As far back as Query Analyzer in SQL 2000, it seemed like there should be a diff tool built in. Especially once we went to SQL 2005, and Management Studio got an interface that more closely tied into Visual Studio, it felt like a database diff tool was a pretty glaring omission.
Microsoft has rectified this problem in Visual Studio 2010, providing what appears to me to be an extremely capable comparison tool that allows for schema and data comparisons, at least in the Ultimate Edition. This morning, I used the new schema comparison tool to script and deploy changes to a test server for a project I am working on. I'm not going to go into any detail here about how tool works or how to use it, as the point of this post is simply to say that I am really stoked about the new tool and especially how nicely integrated the whole thing is into Visual Studio.
As I get a chance to use these tools more, I'll put together a few posts on how to use this new functionality.
UPDATE: As I dug into this more, I learned that Visual Studio 2005 and 2008 also had the schema and data comparison tools, but were only present in the Database Edition and Team Suite, neither of which I was running. I'm not 100% sure how the various editions are going to break down for 2010.
Subscribe to:
Posts (Atom)
