Corey Roth [MVP] : Visual Studio 2008

How to: Change your namespace in a Silverlight application without breaking everything

CoreyRoth — Fri, 23 Jul 2010 20:16:41 GMT

The first thing I do when creating a new project in Visual Studio (regardless of type) is change the project name, assembly name, and default namespace. I like for the names of all these to be consistent. However, I have noticed in Silverlight, you must make changes in five different places for everything to work alright otherwise you will get errors. I’m no Silverlight expert, but I thought this post would be useful for people like me who only dabble in it from time to time.

When you create your new Silverlight project, right click on the project name and bring up its properties. Go ahead and change the default namespace and assembly name just like you would in any other project.

In my case, I change from a namespace of SilverlightApplication1 to DotNetMafia.Silverlight.Test. Here you can see the new assembly name and default namespace. There are two other options to set here, but we will have to come back to it.

At this point, we want to correct the namespace in the existing classes. Let’s start with App.xaml.

I have highlighted the section, I need to change, x:Class. I’ll change it to DotNetMafia.Silverlight.Test like we see below.

Now, we just need to change the namespace in the code behind file App.xaml.cs.

Now, we have to do the same thing to MainPage.xaml. Change the namespace here on x:Class as well.

Then, you will change the namespace of the code behind file MainPage.xaml.cs just liked we did before.

At this point, your code will compile. However, it will not run. If you try to debug it you will likely get a blank page and if you are using Internet Explorer, you will probably see a script error in the toolbar.

Clicking on the error, you can see the following details.

I have to say they have really improved the way you view script errors. Here is the text of the error.

Message: Unhandled Error in Silverlight Application
Code: 2103
Category: InitializeError
Message: Invalid or malformed application: Check manifest

Line: 54
Char: 13
Code: 0
URI: file:///C:/Code/SilverlightApplication1/Bin/Debug/SilverlightApplication1TestPage.html

Remember, I said we had to change an additional setting in the project properties?

This is the problem here. We change the startup objects namespace but never update the project properties to match. You should be able to pick the new namespace of your startup object from the list. This is also a good time to change the name of your .XAP file if you are so inclined. Here is what my project properties looks like when I am done.

At this point your application should compile and run. Now I can view my beautiful Hello World Silverlight application.

Great app huh? Any how, I hope this helps should you encounter the error above or run into issues changing your namespace. It’s pretty simple to do, but you’ll definitely get errors if you don’t get all of your changes made.

A few quick tips for interacting with the file system in Visual Studio

CoreyRoth — Wed, 07 Apr 2010 18:59:52 GMT

I was doing some SharePoint mentoring a while back and I noticed that some developers don’t know about a couple handy items found in various context menus that that I use on a daily basis. Specifically I’m talking about a few things in the context menu that give you the path to the file or open the folder that the file is in. These can be useful when you are ghetto deploying files or you simply want to jump to the file system to grab your .wsp file. Honestly these menu items have been around for a long time, but I hadn’t noticed them until a while back. If you already know about them, you can stop reading here. :-)

The first menu I want to talk about is the context menu you get by right clicking on the tab of any open file. This is from Visual Studio 2010, but its there in 2008 as well. I’m not sure about 2005, but if you are still using Visual Studio 2005, you should be ashamed of yourself.

The two menu items of interest here are Copy Full Path and Open Containing Folder. As expected, Copy Full Path puts the full path to the file in the clipboard. This is great when you have a file open in Visual Studio and you need to upload it via browser File Upload control. You can just paste the path right in and you’re good to go. I use this when I’m uploading BDC application definitions a lot. The Open Containing Folder is useful any time you need to copy the file in your project from one place to another.

If you don’t have a file open, you can make use of another item on the context menu from the Solution Explorer.

This opens the folder the file is in with windows explorer.

Directory structures for source code can be huge these days. Lots of nested folders and it takes time to click through them. I mention these topics today because I’ve watched developers open a new instance of windows explorer and browse through the folder structure every time. Anyhow, maybe you already use these menu options. I thought they were useful and worth a quick mention.

Linking Files in Visual Studio

CoreyRoth — Wed, 20 Jan 2010 15:29:35 GMT

I saw this feature in Visual Studio again the other day and honestly I had kind of forgotten about it. After discussing it with some colleagues, most of them didn’t even know the feature existed. What I am talking about is the ability to create a link between files in Visual Studio. What this allows you to do is actually create a link to a file instead of just making a copy. Now, I don’t want to get into a discussion of why you would never want to do this or how this is not a proper way to implement code reuse. Keep in mind though that you can use it to link other types of non-code files such as an XML file. However, for today’s purpose, I’m just going to link a class into another project. Consider my following example with two class libraries. I want to reuse Class1.cs inside ClassLibrary2.

I have a simple class that looks like this.

using System;
 
namespace ClassLibrary1
{
    public class Class1
    {
        public Class1()
        {
        }
 
        public void DoSomething()
        {
            int x = 5;
        }
    }
}

This class clearly has so much valuable code in it that I have to reuse it in ClassLibrary2, but not make a reference to ClassLibrary2. This is where the Add as Link functionality comes in. The process is simple, using the Add Existing Item menu on the project’s context menu. Navigate to the existing item in the other class library and then make note of the arrow next to the Add button, click on it and choose Add as Link instead.

Once you do that you will have a link to the file in your other class library. You can open it and edit it as normal from the linked location, but it will actually edit the file link. You can tell it is linked in Solution Explorer by the icon.

Notice the link icon on Class1.cs in ClassLibrary2. If you click on the linked file, you can see the path to the file it has linked in the properties (although its cut off here in my screenshot).

Once you are done here, you can make changes to the file from either class library and the original file gets updated. Keep in mind though, if you delete the original file, the link will be broken and you will get an error when trying to view any links. I don’t know how useful this feature will be to all of you, but I think there is a time and place for everything. I can definitely see this being useful in some cases. This isn’t a new feature either. I think its been around since at least Visual Studio 2003, but I could be wrong.

Compilation Error with Generic Handler in Visual Studio 2008

CoreyRoth — Mon, 27 Jul 2009 22:04:27 GMT

Anyone else out there notice that if you add an generic handler to your project that it won’t compile? It appears to be an issue with the template included in Visual Studio and it may have been resolved in a service pack but currently I don’t think so. The file type I am describing is the .ashx generic handler and not the ASP.NET Handler as you can see below.

After it creates the file you might immediately notice there are issues. If you go to compile it, you’ll get errors like seen below.

Luckily, resolving the error is quite easy. You just need to add System.Web.Services to your using block. Once you do that, you can compile successfully and begin building your handler. I just thought I would point this out since I have seen this on multiple systems now.

Recap of last night’s talk on Web Testing with Visual Studio

CoreyRoth — Tue, 28 Apr 2009 15:19:55 GMT

Last night, I had the opportunity to speak at the Tulsa .NET Users Group. I spoke about automating web testing using Visual Studio Team Test. This is usually the post where I post my slides and code samples, but this talk did not have any slides, so I thought I would give a quick recap. In the talk, I showed how to record a web test using Visual Studio Team Test. I showed how to set up a basic validation rule and demonstrated passing and failing tests. Lastly, we ran through a coded test and showed how you can use existing tests to perform load testing. I had a great time giving the talk. Thanks for attending.

Follow me on twitter.

Speaking about Automated Web Testing with Visual Studio Team Test at Tulsa .NET Users Group

CoreyRoth — Mon, 20 Apr 2009 14:19:00 GMT

Next week on April 27th, I have the privilege of speaking about Automated Web Testing using Visual Studio Team Test at the Tulsa .NET Users Group. This is an updated version of the talk I originally gave about four years ago at DTG. At the time, I gave the talk using Visual Studio 2005, but for this talk we’ll be using Visual Studio 2008 and using the added features it brings us. This is my first non-SharePoint talk in a while, so I am excited to be able to talk about a different topic with some new people. I am happy to say there won’t be any slides on this talk, it will be nothing but using Visual Studio. Tulsa DNUG is located at TCC Northeast Campus (3727 E. Apache). It starts at 6pm. Dennis Bottjer has more information on tonight's event. Look forward to seeing you there.

Follow me on twitter.

People, it’s time to upgrade to Visual Studio 2008!

CoreyRoth — Mon, 23 Mar 2009 13:44:20 GMT

I try to stay away from posts like these that don’t stick to how to do something, but I do entitle myself to one or two a year, so here it is. My rant today is about organizations that don’t allow developers to develop using the latest technology. Visual Studio 2008 has been out for well over a year, has had one service pack already and Visual Studio 2010 is well on its way. This means, you could be well on your way to being two versions behind. Telling a developer that they have to develop with Visual Studio 2005 (or older) is like asking him or her to program with one hand tied behind the back. So what do I account for being the most common reasons for not upgrading? I’ve listed the ones I can think of below. Let’s see how we can mitigate some of these issues.

Fear and being uninformed

In my opinion, I would say this is the most common reason. Fear of the unknown.

“If I install Visual Studio 2008, all of my code will break, and I’ll spend days fixing it.”

Possible but not likely. If you were informed about the project, you would know that Visual Studio 2008 supports compiling to multiple frameworks. This means, that your Visual Studio 2005 project can be compiled in Visual Studio 2008 and target .NET Framework 2.0. It does make a slight change to your project and solution file, but that is the only thing that is changed. All of your code will remain untouched. Then when you are feeling adventurous, you can make the move and target .NET Framework 3.5. If it compiled and works as 2.0, I am 99% certain that it will also work against 3.5.

Why am I so certain? Well let’s review the changes to the .NET Framework. The fact that it is called .NET Framework 3.5 is pure marketing fluff. You are still using .NET 2.0, it just has things like WCF, WPF, LINQ, and C# 3.0 added. It essentially lets you call assemblies such as System.Core which contains LINQ and various other things.

“When I upgraded to ASP.NET 2.0, the migration was difficult.”

I agree, sometimes, the migration wasn’t smooth to ASP.NET 2.0. However, ASP.NET 2.0 was a complete overhaul of ASP.NET 1.1. However, Visual Studio 2008, still uses ASP.NET 2.0, so your code is still going to work great. Plus, they added cool things like the LinqDataSource and the ListView control (which is awesome by the way).

Cost

Ok, we are in a recession, I understand that. However, most companies buy Visual Studio in multi-year agreements, which does entitle you to upgrades. Admittedly, I have seen some bigger companies, not buy Microsoft products in volume and buy retail boxes of Visual Studio (which is just throwing money away). I am no expert on licensing, but there is a good chance you may be entitled to the to an upgrade and don’t even know it.

Laziness

Yes, it does take some time to install Visual Studio 2008 and can take even longer to apply Service Pack 1 (which you really want btw). However, how much time are you losing on your project by not upgrading? Have a task where you need to find some values buried in an XML document? In Visual Studio 2005, you muddle with an XPathNavigator and get the task done in 15 to 30 minutes or so assuming you are good with XPath. In Visual Studio 2008, you LINQ to XML to query your XML document and have the values you need in a convenient anonymous type in less than 30 seconds. That is only one example, but the choice seems obvious to me.

IT Administrator or Help Desk won’t allow it

I feel for you if this is the case. It should be the development lead or architect of a project that determines what tools you use, not someone else that doesn’t even use the project. If a manager, director, CIO says which tools you have to develop with, I encourage you to push for change. These people tend to be the most conservative when it comes to change, so they are almost always going to be against it. However, if you can show him or her how upgrading can save the company time and money, they are going to listen.

Client won’t allow it

When this happens, it is usually one of the above reasons. If you are a consulting company or a staff aug, you are there to bring you professional recommendation. If you think a newer version of Visual Studio will save them time, don’t be afraid to recommend it. I even recommend stating which version of the tools you intend to use in the statement of work. It’s been my experience, that when I express to a client how much time can be saved by upgrading, they have been more than ok with it.

Get on the Cutting Edge

I always thing good companies and developers stay on the cutting edge of the Visual Studio release cycles. These people are installing betas of the products, looking to see how new features can make their upcoming projects go faster, and even deploying things on production on betas when the Go Live license hits. Now is that for everyone? Certainly not, there is the right spot on the edge that is appropriate for every company. However, staying on the cutting edge, can make companies look more attractive to clients as well as make developers more attractive to companies. Think about it. Do you want the developer that knows you can use LINQ to SQL (or Entities) to bust out data access code or the developer that is still reading things into a dataset the way you did in .NET 1.0 (not that I am saying ADO.NET is dead by any means)?

So what are some of my favorite features in Visual Studio 2008 (some of these require SP1)?

LINQ – I find new ways to use it everyday – whether it is querying a list, string[], or whatever.
LINQ to XML – Anytime I need to read something out of an XML file, this is the way to go. Great for dealing with repeating sections of InfoPath forms too!
LINQ to SQL – I deal with a lot of projects which don’t need a big elaborate DAL. LINQ to SQL makes this really easy.
Anonymous Types – Use them with LINQ all of the time. Great way to get typed access to XML documents.
Automatic Properties – Wasn’t that excited about them at first, but I use them more and more now.
Property Initializers – Reduces code since you don’t have to create a bunch of constructors to initialize different combinations of properties
Dynamic Data Web Applications – These seem pretty neat, but I have yet to make full use of one
Improved WPF Designer
Better JavaScript debugging
Silverlight support

The list goes on and on, but you get the point. Of course, this is just my opinion on all of these things, but hopefully, I might have convinced a few of you out there that it is time to upgrade. Some developers may be ok with developing with old tools, but many developers find it particularly frustrating. There is nothing worse than the feeling you get when you find yourself reinventing the wheel by manually coding something that was added to a later version of the tool.

VSeWSS 1.3 - Please wait while the installer finishes determining your disk space requirements

CoreyRoth — Tue, 03 Mar 2009 20:48:14 GMT

I have been working on creating a new Windows Server 2008 virtual machine lately, so I decided to grab the latest version of VSeWSS 1.3. I immediately encountered the following error when trying to install.

Please wait while the installer finishes determining your disk space requirements.

The only option is to click the “Return” button and wait. Unfortunately, it never stops. After doing a quick Google search, I came across this post which describes the issue with MSI packages. It wasn’t related to SharePoint but put me in the right direction. This applied to an MSI file though and the VSeWSS download is not an MSI file its an EXE. I figured there was a command line option to extract the MSI and in fact there is.

VSeWSSv13_x86_Feb2009CTP_Build_429.exe /extract <workingfolder>

Just specify a folder you want the extracted file to go into there. Then you can execute the MSI file as such with msiexec and the issue does not occur.

msiexec /i VSeWSS_v13_x86_Build-429.msi

Not sure why I ran into this issue, but in case you do, hopefully this helps.

On a side note, I’m on twitter now.

VSeWSS 1.3 CTP Feedback and Feature Requests

CoreyRoth — Thu, 05 Feb 2009 21:12:10 GMT

First of all I would like to say this tool has improved quite a bit since the last version. However, I still feel that it has a long way to go before a SharePoint developer would actually consider using it. The functionality I am targeting today is the web part functionality. Before that, I'll point out some things I ran into before I could get the product to work at all.

A lot of this is due to the environment I created, but it's worth pointing out in case someone has a familiar environment. When I installed this particular VM, I chose the quick install to save time. As you know this installs a version of SQL Server Express as well as creates Central Admin and your SSP for you running with the Network Service account. This is where the first issue is. The application pool running the VSeWSS web service has to be a member of the Local Administrators group (Administrators if you are on a Domain Controller). This builtin account cannot be added to that group (to the best of my knowledge), so you have to create a new account (which I prefer anyway) to run the application pool for Central Administration and the VSeWSS site. I did all this and I went into the database and gave this account db_owner permission on the config and central admin content databases and for the most part everything works. I can package a solution and deploy it (however I still get an error activating the feature). This was at least enough to get to the point where I could test it.

Now about using the tool itself. I really like the added options to Deploy, Package, and Retract Solutions added to the context menu of your solution. These all seemed to work really well. I was able to create a quick Hello World web part and deploy it. I activated it manually and was able to view it immediately. One thing, I am very appreciative of is the ability to choose between a Full Trust or Partial Trust web part when you create the project. You still have to specify the Code Access Security settings yourself, but at least it is possible now. I am also a fan of the new options to quick deploy directly to the bin folder and 12 hive.

As a SharePoint developer, I put a lot of files into solution packages. Pages, XML files, Master Pages, Site Template Definitions, you name it. I want to be able to put these files in my wsp. I assumed WSP View would have this functionality. You can get to it by going to View -> Other Windows -> WSP View. Maybe, there is functionality there, but I couldn't figure out how to add any files to the package. You have no direct access to the DDF file and there are no menu options to allow you to customize or add files in WSP view. There is an option to add another feature, but you can't customize what files to add along with the feature. Somehow, when you create a new web part project, the .webpart file shows up in the WSP view, but I have no idea how. This by itself, means I can't use this tool. Again, if I am just being stupid and can't find it, let me know. The one thing I will note here is that you can customize the manfiest file here.

Another thing, I found lacking is that I can only add one web part per project. Sure, I can manually create another class, but I want it to generate the .webpart file for me and put it in the solution.

Features I would like to see:

Remote SharePoint Server support - Let me install it on a Windows XP machine (without WSS obviously) and specify the URL to my SharePoint server.
Ability to customize contents of WSP file
Better CAS support - A tool to help determine security policies would be great
Multiple web parts in one project
Better control of what goes into the solution package

I know the product is just a CTP, so hopefully, with some good feedback we can get a tool we can all use. I guess for now its back to manual creation, stsdev, or WSPBuilder. Microsoft has relied on the community too long for SharePoint tools, it is time they produce.

I have also cross posted this to the SharePoint Developer Forum.

Dealing with InfoPath Form Templates in Visual Studio 2008 with TFS

CoreyRoth — Mon, 12 Jan 2009 19:20:05 GMT

I have been building a large number of InfoPath Form Templates in Visual Studio 2008 lately and I have discovered it is can be quite the exercise in frustration when you want to put your files in TFS (or any source control for that matter). There are a number of reasons for this, but it all starts with the fact that the form template designer does not like it when files are read only. Unlike other project types that will automatically check out files that are needed, the InfoPath form template project will not do this.

Before, you begin working with an InfoPath template file in source control, be sure that you checkout (at a minimum) manifest.xsf. For some reason any time you compile, this file must be checked out. On top of that, if you want to publish your form, it seems to require that this file is checked out in all other form projects in your solution. It looks like it does a build solution prior to launch the publish form template dialog. As you are editing your form, other files in the project will more than likely need to be modified, so my recommendation is that you check the entire project.

As you are working, you might come to a point where you receive an error like the following when trying to save your file.

InfoPath cannot save the following form: InfoPath Form Template. The form is read-only.

When this occurs, it really is a bad time because every time I have received it, the form was already checked out and not marked read only. The only solution I have found for this is to close Visual Studio and restart it. This can be particularly frustrating when you have made a bunch of changes to the form template as you will end up losing them. For this reason, I have made a practice of attempting to save the form, before I start making any changes to it.

Another error that you may often run into is the following.

The operation cannot be completed.

This can occur when trying to publish or when trying to open the manifest.xsf file. When this occurs, your best bet is to make sure all files in the project are checked out and restart Visual Studio. If you are lucky, you will be able to open the form or publish it again. If not, my recommendation is to go back to a previous version and hope for the best.

Another issue you might run into occurs when checking in. If you try to check your files in while you still have manifest.xsf open in the form designer, you will get the following error.

The process cannot access the file 'MyTemplate.xsf' because it is being used by another process.

The designer seems to create a lock file so no external process can even read it. Just make sure you close the file first before you try to checkin and you will be good.

WSS 3.0 Tools, Visual Studio Extensions 1.2 running under Windows Vista

CoreyRoth — Wed, 04 Jun 2008 22:02:40 GMT

Back in February when version 1.1 of the Visual Studio Extensions for SharePoint came out, I really complained about the lack of support for Visual Studio 2008 and Windows XP / Vista. Version 1.2 finally came out so I decided to look and see if operating systems other than Windows Server 2003 are supported and I was surprised to see Windows XP and Windows Vista on the list. I immediately downloaded it, tried the installer but saw that there was still a requirement to have WSS installed. Luckily, in the last week or so the guys at Bamboo, posted a utility to allow WSS to be installed on Windows Vista. I decided to give the utility a try and it worked flawlessly. I then tried installing the extensions again and everything worked. The Visual Studio Extensions are nothing all that exciting, but they can be useful from time to time. I am just glad I was able to get them to install.

I did notice that Windows Server 2008 was missing from the list so no telling if it will work there or not.

WSS 3.0 Tools, Visual Studio Extensions 1.2

How to: Use LINQ to SQL without using the Object Relational Designer

CoreyRoth — Tue, 18 Mar 2008 00:54:20 GMT

LINQ to SQL has already proved to be extremely easy to use to create object relational mappings when you have an existing database schema using the Object Relational Designer. This designer is good, but you may not want something that is autogenerating your domain classes. You may want to generate your domain classes yourself. This is actually quite easy and works in a similar manner to other OR/Ms such as ActiveRecord. The thing I like about it is that your domain objects do not have to inherit from some base class that has all of the underlying logic to access the database. Instead you create a custom class separate from your domain objects that inherits from DataContext.

We'll create a simple example of a products table for an e-Commerce web site. Let's start by looking at the domain object. Before you create your domain object start by adding a reference to System.Data.Linq to your class library if it is not already present. You will then need to add a using statement in each domain class for System.Data.Linq.Mapping.

[Table(Name="Products")]
public class Product
{
    [Column]
    public string Name;
 
    [Column(IsPrimaryKey=true, Name="Id")]
    public int ProductId;
 
    [Column(Name="Price")]
    public double Price;
}

The first thing you do in your domain class is decorate it with a Table attribute. An optional parameter here specifies the name of the underlying database table. In this case my domain object it Product but my database table is named Products. I then defined three properties representing columns in the table. The Column attribute specifies that the property will have a corresponding column in a database table. The IsPrimaryKey parameter specifies that the column is a primary key in the database. The Name parameter here also allows you to specify a different column name in the database.

That is really all that is required to create a domain object. You can define a class for each domain object you want and you can also create relations between them (but I won't be covering that here today). Once you have your domain object created, you will need to create a DataContext class to actually be able to query your domain objects. This is also pretty simple. You just expose a property with the generic type of Table<> for each one of your domain objects. The name of the property is what you will use with the DataContext when you are querying with LINQ.

public class StoreDataContext : DataContext
{
    public Table<Product> Products;
 
    public StoreDataContext(string connection)
        : base(connection)
    {
    }
}

Now that you have your domain objects written you will need to create the SQL tables that they represent. You can do this manually, or you can have LINQ create the whole database for you. Just create an instance of your DataContext and call the CreateDatabase method. This method infers the name of the database given the connection string you used. If you did not specify the database, you need to add a Database attribute with the name to your class.

StoreDataContext myDataContext = new StoreDataContext(myConnectionString);
myDataContext.CreateDatabase();

Alright, so now your domain objects and database are created, now you just need to query something with it.

var products = from product in myDataContext.Products
               where product.Price > 49.99f
               select product;

This simple query simply returns any product with a price greater than 49.99. So, LINQ to SQL doesn't have to be completely domain driven. This gives you a lot of flexibility and makes it easy to add additional things to your domain logic if you want to. The downside to this of course it that, when your database schema changes, your domain object is not going to get updated at the click of a button. If you are building your domain objects in this manner though, this is probably not a concern to you though.

How to: Remote Debugging a Web Application

CoreyRoth — Wed, 05 Mar 2008 19:54:18 GMT

After talking to many different developers, I appear to be one of the few ones that have gotten remote debugging to work with a reasonable success rate. That is why I have decided to post on it today. Everything I am writing today is based upon my experience in what has worked and may not necessarily be a best practice. I actually posted about this once in the past, but I think its worth going into more detail.

Preparing Your Server

The first step is to install the remote debugging tools on your server. To do this, run rdbgsetup.exe contained in the Remote Debugger folder of your Visual Studio 2008 or Visual Studio 2005 installation media. Be sure and pick the correct processor architecture (x86, x64, or ia64). To use remote debugging, you can either install a Windows service or run an application. Although, the service is more convenient if you are going to be debugging a lot, the application is a lot easier to get up and running.

Running the Remote Debugger

Once you have got the remote debugger installed, I typically use remote desktop to log into the server and start the Visual Studio 2008 Remote Debugger. This really will only work right if the account you are logging into the server with is also the same account you log into on your client machine that is doing the remote debugging. If its not, there are some complications and you'll legitimately get the error I have posted about here.

One thing to note. The Visual Studio 2008 Remote Debugger is not backwards compatible with Visual Studio 2005. Therefore, you need to be sure and install the Remote Debugger from the same version of Visual Studio you are debugging with. It is ok to have them both installed at the same time, but I don't believe you can have both running at the same time (need to confirm though).

Preparing your environment

When you are ready to start remote debugging, start by compiling your web application. You then need to copy the DLL and PDB file from your bin/debug folder to the bin folder of the web application on your server. Not doing this is one of the most common causes for a breakpoint to never be hit when remote debugging. If the DLL and PDB do not match between the client and the server, the breakpoint will never be hit.

Start Debugging

Once everything is in place, it is time to start debugging. To do this, click on Debug -> Attach to Process in Visual Studio when you have your web project open. If everything is good and all the permissions match up, you should be able to type your server name into the Qualifier box and view its processes. Typically, when I do this, I am a local administrator on both the client and the server. I think this is more permission than needed though. I believe there is a Remote Debuggers security group that can be used.

The way you start debugging is by attaching to w3wp.exe. However, it is more than likely that you will have multiple application pools on your server (especially if you are using SharePoint) which means more than one w3wp.exe process. To determine which w3wp.exe to use, you can just pick one arbitrarily and then examine the modules window in Visual Studio and look for your DLL. You can also look at the username on the process and see if it matches the one on the application pool you want, or you can use a cscsript command to get a list of the w3wp.exe processes and which site they match in IIS.

Once you have attached to the correct w3wp.exe, set a breakpoint open a web browser and hit the page you want to debug. Assuming you set a breakpoint and did everything correctly, the breakpoint wont give you a message that the symbols could not be loaded and the breakpoint cannot be hit. If you were able to set your breakpoint, open a web browser and hit the page you wanted to debug. If all goes well, your breakpoint will be hit and you can debug just like it was on your local machine.

How to: Hack a Class Library Project into a Web Application Project

CoreyRoth — Fri, 22 Feb 2008 20:09:24 GMT

Kind of a weird tip here, but I have ran into a situation where I have needed to do this. Basically, I have had an existing class library (for SharePoint development) and for some reason, I have decided I need to add ASP.NET file types to it (i.e. User Controls, Master Pages, etc.). A class library doesn't have these file types in the Add Item menu so you need a Web Application Project. When it comes down to it a Web Application Project really is the same thing as a class library, it just has some extra settings. So when it comes down to it, you would either have to recreate the project and add your existing files back into it or just hack the XML of your .csproj file. I obviously prefer the latter.

To do this, start by Unloading the Project by right clicking your project and choosing Unload Project. Next Right click on your unloaded project and choose Edit <PrjectName>.csproj. Paste the line below in the first ProjectGroup element. Usually Visual Studio puts it underneath the ProjectGuid element.

<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

That is the only change that is required. There are some optional settings that you can put in regarding the configuration of Cassini, but none of them are required to get you going. You can always configure them in Visual Studio. Once you have made the change, save the .csproj file and Reload Project. Once the project is loaded, all of the ASP.NET file types will be present in your Add Item menu. When you compile, it will still compile everything down to a single DLL and you can deploy it just as if it was a regular class library.

WSS 3.0 Tools, Visual Studio Extensions 1.1 is nice but still disappointing

CoreyRoth — Tue, 12 Feb 2008 15:28:00 GMT

At the ODC (where I should be this week), Microsoft announced version 1.1 of the Visual Studio 2005 extensions for Windows SharePoint Services. This brings a lot of great new project templates and the ability to edit wsp files. What is it lacking? Well unfortunately Visaul Studio 2008 support. I have already moved most of my SharePoint projects into Visual Studio 2008 and having no support for it is completely frustrating. We're going to have to wait until June to see that support in version 2.0.

Another, thing that really disappoints me is that it still requires Windows Server and SharePoint to be installed just to install the extensions. I use Virtual Machines to do development some, but I also do a lot of development from Windows XP and Vista and make use of Remote Debugging. I understand the complexities of running things over the network, but can I at least install the project templates? I am willing to deploy the files myself, it doesnt have to be automatic for me.

If you are still using Visual Studio 2005 on a Windows Server, then go ahead and install them because they will be pretty useful. Here is the link.

http://www.microsoft.com/downloads/details.aspx?FamilyID=3e1dcccd-1cca-433a-bb4d-97b96bf7ab63&displaylang=en