Visual Studio Team Test: Web Tests and IE8

I ran into an interesting problem while trying to create a demo for Visual Studio 2008 using the Web Test macro recorder (IE plugin) and Internet Explorer 8. 
 
The test website I had was on my local PC so I started recording and typed in the localhost address.  Suddenly, the macro recording stopped and only had a message stating the the recording had to be initiated via Visual Studio.  Also, the recording had stopped within Visual Studio as well … no steps were added to the test script.
 
After scratching my head, searching the net, and gazing into the air I realized that IE was switching from the Internet Zone (for the default about:blank page) to the Local Intranet Zone (for my web site).  To fix this, I manually added about:blank to my list of Intranet sites and everything worked as expected.
 
I am not sure if there is any more legit fix to this but this worked fine for me!
Advertisements

Proper source code management of your Visual Studio 2003 solutions

Source Control, and thus products like Visual Source Safe or CVS, is obviously an important part of your software development life cycle but can also be a source of frustration (especially for ASP.Net web projects).

It is important to have a standard, repeatable method for any process in your SDLC including your project structure and source code management. Visual Studio makes this even more important for ASP.Net projects given it’s natural tendency to put all of your web projects under wwwroot. While this is a perfectly acceptable solution for some teams, many prefer to have their entire project under one folder structure. Reasons for this range from obsessiveness to easy of backup to convenience. Below is a good (mission tested) method for source code management in Visual Studio.

Step 1: Decide on your folder structure in advance
Through experience, anecdotal and empirical evidence, common sense and (of course) trial and failure many people in the industry have come to agree that to following folder structure just makes sense.

…SystemNameSolutionNameProjectName

System Name represents an overall name for your system (like EcommercePortal) and allows you to group not only more than one Visual Studio.Net solution but other components of your project as well (documentation, diagrams, etc.). Solution Name corresponds directly with the name of your VS.Net solution. If the folder does not represent a VS.Net solution then common sense prevails on your naming and hierarchy from this point on. Finally, Project Name is simply the name of your VS.Net project where the solution folder can have one or more projects in this branch.

The root location of this structure does not initially matter (e.g. on team member can use d:SystemName… while another uses his My Documents folder); However there are certain cases where the full physical path makes a difference. InfoPath projects, for example, become much more easily managed if all team members are using the exact same physical path.

Step 2: For ASP.Net web projects, pre-create your folder structure
At this point, if your solution is going to contain one or more ASP.Net web projects you should create the folder structure in advance in preparation for the next step. The following would be an example of a full folder structure for an Ecommerce web front-end:


c:ProjectsEcommercePortalEcommerceSolutionEcommerceWeb

Please note: In Visual Studio.Net 2003, the folder and project name of your ASP.Net web project must match the name of the web (virtual directory) under IIS. This is a good time to choose a logical name for your web application before you have added any value.

Step 3: For ASP.Net web projects, create your virtual directory
Normally, VS.Net would create all ASP.Net web projects (new or from Source Safe) under the default website’s directory (usually c:inetpubwwwroot). However, it is often desired to keep all of your project files in a single folder structure. To coerce VS.Net to create your web application within this folder structure you simply need to setup a virtual directory with the same name as your web project and folder. In above example, you would create a virtual directory named EcommerceWeb pointing to that directory.

The easiest way to create a virtual directory is to do the following:

  • Locate the physical folder user Explorer
  • Right-click the folder name (EcommerceWeb) and select Properties
  • Click the Web Sharing tab
  • Click Share this folder and accept the default settings
  • Click OK until all property dialogs are close

Step 4: Create your solution

At this point, you can finally begin creating your Visual Studio.Net solution that will contain your projects. Using Visual Studio, create a new Blank Solution, name it appropriately, and save it in the directory you created above. Continuing this example, your solution file should be created as follows:

c:ProjectsEcommercePortalEcommerceSolutionEcommerceSolution.sln

Step 5: Add the empty solution to source control

Now that you have your folder structure and blank solution you can start putting it into your source control system. This will pre-create the structure you have so far and make the rest of the processes a little bit simpler. The following list demonstrates this using Visual Source Safe:

  • Right-click the solution in your Solution Explorer and select "Add Solution to Source Control …"
  • Assuming no previous structure exists under VSS:
    • Single-click the root ($/)
    • Enter your system name (Ecommerce) into the text box and click create
    • Single-click the newly created project (Ecommerce) and click OK
  • If your system/project already exists under source control, simply select the system name and click OK

Note: VS.Net will automatically create a sub-folder/project for your solution directory (EcommerceSolution) so there is no need to create or select this in your source control dialog.

Step 6: Create your project(s)

You can now add projects to the solution as you normally would with one note: For ASP.Net projects make sure that you name your project the same as the virtual directory you created above. If you are prompted, check out your solution file.

Step 7: Bind your project to source control

With the exception of ASP.Net projects, your solutions will be properly created under the solution directory when you check them into source control. However, ASP.Net projects will not be created where you anticipate. The following instructions will re-bind your ASP.Net project under the correct hierarchy:

  • Open your source control client
  • Under the solution folder/project (EcommerceSolution) create a new folder/project with the same name as your ASP.Net project (EcommerceWeb)
  • Back in VS.Net
  • Click File->Source Control->Change Source Control
  • Click on the link for your web project (EcommerceWeb)
  • Click the Bind button
  • Select the folder/project you just created (EcommerceWeb)
  • Click Ok Twice
  • If prompted, select "Continue with these bindings"
  • If prompted, allow VS.Net to check-in any files
  • In your Solution Explorer, check-in the entire solution

Final Step: Getting the source tree from source control

You now have your entire system, solution, and projects checked into your source control system in a manageable hierarcy. However, there is still one more precaution the rest of your team needs to take before they begin working with this system: they need to get the entire source tree back out of source control without undoing any of the above steps.

The safest and cleanest way of getting the source tree is to follow Steps 2-3 above, then use Visual Studio.Net’s "Open from Source Control" wizard (under File->Source Control). You will need to navigate down to folder/project where your solution is under source control and make sure your local path in the dialog matches what you created in Step 2.

Another method is to use your source control client to get a local copy of the source tree (outside of VS.Net) and then create your Virtual Directories (as in Step 3) for your web projects BEFORE you open the solution in VS.Net

Using Jalindi Igloo plugin (CVS) with VS.Net … successfully

If you need to use CVS for source code control on your Visual
Studio.Net project, here is a quick way to enable the latest version of
CVS in combination with the free Visual Studio.Net add-in: Jalindi Igloo.
The
plugin does have it’s own install program and scripts but the problem
is that it uses an older CVS library and does NOT work well with SSH
connections to a CVS repository. While the older version may work
well for you, I certainly suggest you always use the latest CVS client
for at least security reasons.
First, download all of the following packages:

Next,
install the CVSNT client as you normally would making sure to note the
location of the install directory. Once that is installed, open
the beta version Igloo archive and copy the files into the CVSNT
directory (ignoring the paths). But first, please note:

*** DO NOT OVERWRITE ANY FILES IN THE CVSNT DIRECTORY ***

The
beta igloo client has some older CVSNT files and you don’t want to mess
up your install. After that, you just need the nice VBS scripts
provided with the release version of Igloo. One script will
register the plugin as your SCC provider in VS.Net and the other will
restore SourceSafe as your client.