Ran into a real pain in the @ss today. While working with Team Foundation Server I was refactoring a couple of projects and at one point I needed to "Undo" my changes. This is normally accomplished by what you see on the left.

Well, to my dismay, as soon as I clicked on that button, Visual Studio 2005 would HANG. I mean, it would just stop. The only way to get it to respond (and yes this is odd)  was to go to Task Manager, then right click on the application (on the Applications tab) and then click "Minimize" then click "Maximize" and the app would respond. Unfortunately the "Undo" didn't happen though.

I looked all around the net, and couldn't find anything. I did the following...

devenv /resetskippkgs (didn't work)

devenv /resetsettings (or something like that - anyway - it didn't work)

I also installed hot fixes that seemed to be related to this problem. Didn't work. Reboot - didn't work. Installed last nights updates - didn't work.

I repaired Team Foundation Explorer - didn't work.

As a last resort I decided to take VS2005 back to its clean slate state by firing off this command. This command is kind of hidden and is not supported by Microsoft (details - all the way at the bottom of that link).

Fix: devenv /resetuserdata

MSDN - Disclaimer: you will lose all your environment settings and customizations if you use this switch. It is for this reason that this switch is not officially supported and Microsoft does not advertise this switch to the public through devenv /? command.

After I fired that bad boy off, waited a few minutes and fired up VS2005 and everything worked again. Thank the big baby jeebus for not having to re-install VS2005 or use a MS Support call. 

I was creating a solution file for an application at a client and I got this error message.

Sara Ford explains why this happens here. The OS limit is 260 chars for the MAX_PATH variable according to Sara Ford's blog.

So how do you get around it? In this case, Visual studio was creating a folder for my solution. So I just created a solution somewhere else on the system and copied it over to my destination folder. I knew that the files wouldn't be exceeding the 260 character limit anytime soon so it wasn't a problem.

But what if you do need to exceed the file path? Easy, create a file share. Share a folder as a new drive on your machine, then create the solution on the new share (its still in the old folder) but you're referencing it with the new path. Kind of a kludge, but it works.

A quick tip for those of you who don't use tools like ReSharper that automatically put the attribute quotes in for you when typing HTML.

Don't you hate it when you're typing in the HTML window of an ASPX page and you have to type in the quotes for an attribute value on element? I do too.

You can fix this by going to Tools > Options > Text Editor > HTML > Format

and checking the box that says "Insert attribute value quotes when typing".

Check out this short clip that I made to see exactly what I'm talking about (there is NO AUDIO on this clip)

Click the image to view the screencast-clip.

I recently had a problem that plagued me the last couple of weeks.

Problem: When I pressed F5 or CTRL + F5 or even "View in Browser" from Visual Studio (in an ASP.NET project) Internet Explorer would load. If I had any breakpoints set, the debugger would break, and then I could continue after debugging (or, if I didn't debug the project would continue to load as normal -- in Internet Explorer). Once the project continued to load in Internet Explorer (IE), IE would HANG.

I'm not talking a 5-10 second load. I'm talking 2-3 minutes!! After the initial load, the application would load as expected. I could hit refresh, everything and it would load as expected. Unfortunately this isn't a feasible solution when I need to debug on a normal basis and I cannot be waiting 2-3 minutes for the debugger to start.

The weird about this is... if I opened IE and went to ANY WEBSITE the site would load instantly. The problem was only with ASP.NET projects, making me thing it had to do with the local cassini web server.

Resolution: After some reading, I came to the conclusion that it could be related to a proxy server. I took a look, NOPE, no proxy server here. So then I started poking around with the system. There were no event logs for anything relating browser or .NET issues. I could not find anything related to this issue, other than a couple people having the SAME exact problem.

On a fluke I decided to hit F5, and then while the enormous load time was taking place I started FireFox. I copied the URL from IE (which looked something like: http://localhost:49696/default.aspx) and then posted it into the address bar of FireFox and hit Enter. To my amazement, the page loaded immediately. But  IE was still hanging, and waiting.

After changing some settings in the Internet Options panel of IE I decided to reset IE's settings (see below).

After resetting everything, everything started working again. I'm not sure what setting had started this behavior, but I do know that something in my Internet Settings got changed. Over the next week I'm going to attempt to recreate the issue, and if I'm able to, I'll post the solution here.

But if you're having this same problem, reset your settings in IE!

Jeremy D. Miller has a great post on keeping source code where it belongs. The thought process behind this is that code should be where YOU would assume it would be. If its data access code, it should be in a project/namespace that is something like Data Access or DAL or Data or something that represents the lower layer of the architecture. If its the business rules/tasks the files should be in a project called Business Rules, or BLL, or Tasks, or something similar. It makes sense, just think about this -- if you walk into a business and are given a project that was created by another developer and you're getting a ADO.NET Exception, you'd expect to find the code Data Access code in a Data Access layer, NOT in the code behind. I should not have to hunt down where you put your data access code.

We're talking about basic separation of concerns. The thing is, many developers lack these concepts because they're under the assumption of "I can write this the correct way, and it will take me 2 weeks, or I can do it quickly and it will take me 2 days." This may not matter when the application is running for a few months, but when you are asked to change the data provider from SQL Server to Oracle, or remove the web service calls and replace them with RPC calls, you're going to find yourself in a world of hurt because you didn't set everything up correctly. At this point they have amounted a large amount of Technical Debt.

He also noted that a large number of people were now using Ruby On Rails (RoR) as their development platform and I won't deny that I also believe that Ruby/Rails is huge right now. Tons of shops are running RoR and even Martin Fowler said on Hansel Minutes that ThoughtWorks was doing about 40% (or more) of their business with Ruby. The key point Jeremy brought up is that "RoR forces web developers into a bit of a straight jacket, but that's a good thing in a way." I completely agree. RoR enforces a consistent source code tree layout which allows for developers to easily find there way around a project. "Developer A" can create a project with RoR and then "Developer B" can come along and take a look at it and be familiar with the code layout and structure. The RoR community has agreed that this is the basic way to organize a project and it seems to be working for them.

So what about .NET? Enter Tree Surgeon. Right now, its a stand alone application, but in its near future it should be implemented as a template in Visual Studio 2005/2008. So what is it? It's a application that will create that straight jacket that Jeremy spoke of. It gives the developer a basic set up of layers, unit tests, code coverage and build script. It builds the entire source code directory and allows you to build on top of it. The source code layout follows a white paper written by Mike Roberts. I've been using it for quite awhile and I'm one of the developers on the project. I recently updated the source to allow creation of Visual Studio 2005 projects. Please note, this is only on the source and has not been reflected on the production release. Download the source, run it and then choose a application name, and generate the project source directory tree. Open the solution file and your application is ready to go.

The best part is that its easy to integrate existing projects into this format. I've done it quite a few times to allow for easy integration into my clients CI environment.

If you have any requests for Tree Surgeon, please visit the Issue Tracker page and submit and issue.

Enjoy!

Recently while poking around in Tools --> Options of Visual Studio 2005 I found a setting that allows for the creation of temporary projects. I wish I had found a long time ago, yet for some reason I breezed right over it.

The Visual Studio 2005 Temporary Project

The temporary project will be created in memory and will not be persisted to the disk. Another benefit is that it will not show up in your recent project list. If you decide to close the project Visual Studio 2005 will prompt you with this dialog box:

Supported Project Types

All C#, VB.NET, and J# projects are supported. If you have the Web Application Project installed, you can even create throw away web projects projects too.

 

How To Enable

Go to Tools --> Options and uncheck "Save new projects when created" as seen below.

 

See this MSDN topic for more information.

There are a lot of developers who write custom JavaScript or need to debug pre-written JavaScript, yet do not know that they can debug it in Visual Studio 2005. This is a fairly simple process.

Visual Studio offers the developer the ability to utilize the IDE to debug, just like you would debug if you are debugging .NET code. How? Very simple, the "debugger;" key word.

How It Works

First, you must enable script debugging in Internet Explorer (we will get that in a minute, first lets look at some code).

To debug: Write your JavaScript and place the "debugger" keyword where ever you want the code to break into debugging. The JavaScript interpreter hits this keyword and halts execution and returns the control back to the IDE. This is like setting a breakpoint inside of Visual Studio.

Example

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="JsDebuggerExample._Default" %>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
<script type="text/javascript" language="javascript">

var myJsonVar = {
firstName : "Donn",
lastName : "Felker"
};

debugger; // The code will break right here and return to the IDE for you to debug.

</script>
</head>
<body>
<form id="form1" runat="server">
<div>

</div>
</form>
</body>
</html>

This will allow you to break into the code. When control returns to the IDE, it looks like this:

 

How To Enable in Internet Explorer

You'll need to uncheck a few boxes in the advanced section of Internet Explorer to enable script debugging. If you dont, script debugging simply wont work. It will not break and you'll be left scratching your head wondering what you did wrong.

Go to Internet Options inside of Internet Explorer

Then go to the Advanced Tab and Uncheck "Disable script debugging (Internet Explorer)" and "Disable script debugging (Other)"

Click "Ok".

Now place your "debugger" keyword anywhere in your JavaScript. Fire up the page through Visual Studio and get your debug on.

:)

 

At work, we just upgraded our machines to Quad Xeon x64 machines with four gigs of ram. NICE..... :) But for some reason the manufacturer loaded 64 bit XP, even though we requested Vista. We upgraded it to 64 bit Vista quite easily, problem solved.

I did run into an issue while installing Service Pack 1 for Visual Studio 2005. I was attempting to install the SP1 Vista Update and I kept getting this error that told me that the proper "patches" were not in place, therefore the SP1 Vista Update would not install. To resolve this error you have to actually install SP1 (the regular one) and then the update. IMHO the documentation isnt that great in this area, I got confused...  See for yourself:

"For developers using Visual Studio 2005 on Windows Vista, Microsoft provides an update to Service Pack 1 called Visual Studio 2005 Service Pack 1 Update for Windows Vista. This update builds on the improvements made in SP1 and delivers a first class experience for developers wanting to take advantages of the new features in Windows Vista."

I was taking this as "this is the SP if you're on Vista".

So... to upgrade to SP1 on Vista... do the following:

1. Install SP1

2. Instal The SP1 update for Vista

3. Get you're code on...

Warning:
A: To give notice to beforehand especially of danger or evil
B: To give admonishing advice
C: To call to one's attention

With that said, we could infer that a warning is something that says "Hey, this is kind of important, you might want to watch this." To me, in .NET Development, a warning means I've done something wrong, I've created an error.

To ensure my builds are top notch, I have updated my projects to treat Warnings as Errors. This allows me to be notified of something immediately. If a warning occurs, its foresight into the future. Warning: "This is what could happen." Pretty much that means, you should probably fix that right now. Therefore I dont let builds complete if there are warnings in certain projects.

Here's how to do it...

1. Go to the project properties and select the Build Tab.
2. Select "All" under Treat Warnings as Errors
   

3. Save and build.

Now, lets say you have a variable thats created but not used in a method somewhere, you'd get an error screen like this:



The build will fail locally as well as on your build server.

This will help alleviate errors in the future that may be caused by something that was a warning two months ago. :)

You can also accomplish through the command line compiler:

csc.exe /warnaserror

This compiler switch will treat warnings as errors.

*Note: You might want to leave this option in its default state for projects where a warning is ommitted automatically, like set up projects that publish to a local system. This is something that I'm ok with as we publish it locally anyway.