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"
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.
Friday, February 5, 2010
Trying out the BlogPress iPhone app
This is just a test post to see how well the BlogPress iPhone app works. So far, so good. Not as comfotable as posting from my laptop obviosly, but for blogging when I'm not at my computer, it seems pretty adequate.
Social Media and Personal Branding - Some Initial Thoughts
A couple of months ago, my employer(Aptera) hosted a discussion on social media, presented by TQM Network. The main discussion points were around use of social media such as Facebook and Twitter within the context of business. A couple of specific points really stuck with me, and have guided my use of social media since then.
First, if you use social media, and also happen to work for a company that someone else owns (that's most of us, yes?), then whether you like it or not, everything you do or say on Facebook, Twitter, MySpace, LinkedIn, or any other social media network represents not only you, but the company you work for. There is vast truth in the idea that every employee of every company is a salesperson, for better or worse. How you represent yourself, both in person and in cyberspace can and does give people an impression of what kind of company it is that you work for. Potential customers make conscious and unconscious decisions about whether or not to do business with your company based on more than just what the salesman says. And since most of us would prefer to keep our job, it makes a lot of sense to do our part to help our respective employers put their best foot forward. The bottom line here is that we need to always remember that everything we post on the internet can and does contribute to the impression that the world has regarding the company we work for.
The second topic that I walked away with was that of "personal branding". Just as everything a company does collectively establishes their corporate brand, so it is with individuals. Everything you post on the internet collectively adds up and establishes your personal brand. Once you realize that, you then have some decisions to make about what you want that brand to look like. For example, do you want your personal brand to say that you are a trustworthy, professional person? Or, would you rather let everyone know that you spend most of your free time hungover? It's an individual decision, but let there be no doubt that whether you actively make that choice or not, you are building your personal brand, one way or another.
While there is no single "right answer" on how best to build a brand, there is one word that I try to keep in mind: consistency. You should use common profile and background images across all of the social media networks that you use, including IM clients. For example, I have the exact same profile image on Facebook, LinkedIn, Twitter, Google Talk, and Windows Live, as well as this blog. I also am currently using that same background image on my laptop, so that as people see it, they will recognize that same image online.
I've really just scratched the surface here on the topic of how people represent both themselves and their employer in social media. I am certainly not an expert, I just wanted to get some of my initial thoughts out here with the hope that I can start a discussion on the topic. I welcome any thoughts you may have on the topic, so feel free to comment here or drop me an email at shannonneumann@live.com.
First, if you use social media, and also happen to work for a company that someone else owns (that's most of us, yes?), then whether you like it or not, everything you do or say on Facebook, Twitter, MySpace, LinkedIn, or any other social media network represents not only you, but the company you work for. There is vast truth in the idea that every employee of every company is a salesperson, for better or worse. How you represent yourself, both in person and in cyberspace can and does give people an impression of what kind of company it is that you work for. Potential customers make conscious and unconscious decisions about whether or not to do business with your company based on more than just what the salesman says. And since most of us would prefer to keep our job, it makes a lot of sense to do our part to help our respective employers put their best foot forward. The bottom line here is that we need to always remember that everything we post on the internet can and does contribute to the impression that the world has regarding the company we work for.
The second topic that I walked away with was that of "personal branding". Just as everything a company does collectively establishes their corporate brand, so it is with individuals. Everything you post on the internet collectively adds up and establishes your personal brand. Once you realize that, you then have some decisions to make about what you want that brand to look like. For example, do you want your personal brand to say that you are a trustworthy, professional person? Or, would you rather let everyone know that you spend most of your free time hungover? It's an individual decision, but let there be no doubt that whether you actively make that choice or not, you are building your personal brand, one way or another.
While there is no single "right answer" on how best to build a brand, there is one word that I try to keep in mind: consistency. You should use common profile and background images across all of the social media networks that you use, including IM clients. For example, I have the exact same profile image on Facebook, LinkedIn, Twitter, Google Talk, and Windows Live, as well as this blog. I also am currently using that same background image on my laptop, so that as people see it, they will recognize that same image online.
I've really just scratched the surface here on the topic of how people represent both themselves and their employer in social media. I am certainly not an expert, I just wanted to get some of my initial thoughts out here with the hope that I can start a discussion on the topic. I welcome any thoughts you may have on the topic, so feel free to comment here or drop me an email at shannonneumann@live.com.
Wednesday, February 3, 2010
Classic ASP - AspEnableParentPaths
I was debugging some Classic ASP code recently, as part of building out a new development server, and I ran across an error that I hadn't seen before:
The Include file '../MyFolder/Includes/MyPage.asp' cannot contain '..' to indicate the parent directory.
The answer here is very simple, but not obvious if you haven't had to deal with it. There is a setting in IIS called AspEnableParentPaths, which allows for this use of parent directory references. Back in IIS5, this was enabled by default, but starting in IIS6, it was disabled by default for security reasons. This makes sense, especially as use of classic ASP tapers off. However, if you inherit some old code, it can pop up and cause an error, as it did for me.
Here are a couple of links to instructions for configuring this setting in IIS6 and IIS7, respectively.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/40993ff2-22c3-48a9-ba01-1056a9425a1e.mspx?mfr=true
http://blogs.iis.net/bills/archive/2007/05/21/tips-for-classic-asp-developers-on-iis7.aspx
The Include file '../MyFolder/Includes/MyPage.asp' cannot contain '..' to indicate the parent directory.
The answer here is very simple, but not obvious if you haven't had to deal with it. There is a setting in IIS called AspEnableParentPaths, which allows for this use of parent directory references. Back in IIS5, this was enabled by default, but starting in IIS6, it was disabled by default for security reasons. This makes sense, especially as use of classic ASP tapers off. However, if you inherit some old code, it can pop up and cause an error, as it did for me.
Here are a couple of links to instructions for configuring this setting in IIS6 and IIS7, respectively.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/40993ff2-22c3-48a9-ba01-1056a9425a1e.mspx?mfr=true
http://blogs.iis.net/bills/archive/2007/05/21/tips-for-classic-asp-developers-on-iis7.aspx
Bad, Bad, Blogger!
Yes, I would call myself a bad blogger (slinks away with tail between legs)... Or, more to the point, I am an inconsistent, unfocused blogger. I have always just posted stuff here in a random fashion, with no real thought about the overall focus or intent behind any of it. Most of the blogs that I read on a consistent basis do not suffer from this affliction. Rather, they are extremely focused, with new content coming out on a fairly consistent basis. Quite the opposite of what one finds when they land on my little piece of the blogosphere.
I have 'promised' several times before to write new content daily, or weekly, or whatever frequency tickled my fancy at the time... Obviously, that didn't work out so well. So, I will make no such promise at this time. This post is merely meant to serve as a reminder to myself (and to anyone else who reads this and cares) that if I want them to come, then I need to build it. But, not just build a random mess. Build something they actually want to come back to.
I have 'promised' several times before to write new content daily, or weekly, or whatever frequency tickled my fancy at the time... Obviously, that didn't work out so well. So, I will make no such promise at this time. This post is merely meant to serve as a reminder to myself (and to anyone else who reads this and cares) that if I want them to come, then I need to build it. But, not just build a random mess. Build something they actually want to come back to.
Subscribe to:
Posts (Atom)
