Since my InfoPath 2007/InfoPath Forms Services project has ended you will start to see more posts on my blog about other SharePoint related things and less about InfoPath 2007/InfoPath Forms Services.  My new project is currently in NYC and it will last until March 31^st.  The project is a 100% different than my last project and I'm sure I'll be learning a lot of new things for this blog.  This post is from another project that I'm doing on the side and I just wanted to share a small piece of it with everyone.  If you're attending the South Florida Code Camp then you will get the full picture of everything if you attend my second session "Creating custom commands for STSADM with C#".  Later in February I'll also do a couple of posts on my blog to explain more of the details if you can't attend the code camp.

Ok, enough of my babbling and now to the details of the post.  A few weeks ago I needed to extend the STSADM utility to do a couple of things that it current doesn't have commands for or at least I couldn't find them.  When I built the initial project and deployed the assembly and started to test everything I ran into problems with the code (I wish I could write perfect code).  I struggled trying to get all the code working correctly without having the capability of debugging the code while it ran.  I could have done the old "Console.WriteLine" but I didn't want to go through this approach because I was tired and it would have been way too tedious for me.  This was really frustrating and I decided to figure out what needed to be done to make debugging an option.  I did a little searching but couldn't find anything that helped me (probably not using the correct search words).  When I started to really think about the whole scenario it reminded me about onetime I had to write a Windows Service and I ran into the same type of problem.  To solve that problem I added the "System.Diagnostics.Debugger.Launch" command to my code so I could debug my Windows Service.  So I figured what the heck and I added it to my code and everything complied without a problem.  I deployed the assembly and ran my custom STSADM command and then the Visual Studio Just-In-Time Debugger window popped up as expected.

Since I had already had the code project open I just highlighted that line and clicked the "Yes" button to debug my code.  If I didn't have the code project already open then I would click "New instance of Visual Studio 2005" and the code would automatically loaded into Visual Studio 2005.  Even if you don't have the code project on the server but have the "obj" folder and all its content then debugging is still possible (at least from my experience it is).  When the debugger is ready your code will have a green arrow next to it like the image below.

At this point I usually hit the F10 key and then everything changes to the correct colors and everything works as normal. 

When I got the debugging working with my code it was a lot simpler to see what was wrong with the code.  Then I started to test all the different options for my custom command and the debugger launching all the time started to drive me nuts.  I guess everything is not perfect but then it dawned on me what if I just add a debug option to the command string.  Something like "-debug" and if that's present then launch the debugger.  I thought it could work so I added the extra code to my project to make it happen and compiled everything and moved the assembly into the GAC again.

I went and tried my command again without the debug option and everything ran like normal and then for the big test I add the debug option and the debugger launched and everything worked just as I hoped.  Now I have complete control when the debugger will launch and I will no longer have the nuisance of the debugger launching every time. 

This was a great learning experience for me in many different ways but it really helped me open my eyes on making things more functional and user friendly by taking a little extra time to think about what could be done.

Cheers

When living in the InfoPath and SharePoint world I sometimes don't really get to know how to use some tools that great until I get a stray project that forces me to do things that I normally wouldn't do on a day to day basis.  Recently I've had two projects like that and fortunately for me I've learned a bunch of new stuff that probably most developers learned years ago when the tools were first released.  This post is about me finally figuring out how to switch back from Visual Studio 2005 "IIS Web Server" debug mode to "Visual Studio Development Server" mode.  In Visual Studio 2005 web projects have this properties tab called "Web" and on it you can specify either to run debug from "Visual Studio Development Server" or "IIS Web server" and both of these options have their pros and cons but I'm not going to get into that because that is another blog post if you ask me.  Below is an image of the properties tab Web.

Usually when I'm starting out on a new project I've always found myself always using the "Visual Studio Development Server" for debugging but once I start publishing my sites to IIS then I usually switch to "IIS Web Server" but one of the biggest problems that I've had was not being able to switch back to "Visual Studio Development Server" mode and successfully publish my code to the desired IIS website.  Whenever I would switch back and try to publish my code to the IIS website I would get this error.

This error has haunted me for about 2 or 3 projects and I finally got tired of it and started to do some searching to find a fix but was unable to.  So I started messing around with the settings on the Web properties tab and noticed that the "Project Url" and "Override application root URL" textboxes were getting pre-populated and in most cases I was changing the values to point to the IIS website I published to.

Once I noticed that these values were not being cleared out when I would click on the "Use Visual Studio Development Server" radio button then I decided to clear them out manually and then try publishing again.  When I tried the publishing everything worked and the error went away.  So when you switch back and wan't to use the publish feature but you can't because of the error message, just make sure everything is cleared out and looks like this image below.

I'm sure everyone in the world knows this but since this was my first I figured I would blog it.  Hope everybody had a great weekend.

Cheers

I'm sure this is posted in a 100 different spots but I just learned about it before I went on vacation and wanted to share it.  It has never really bothered me at guessing which w3wp.exe process to use for debugging SharePoint code but when I was working with Joe (new guy) he saw what I was doing and he told me there was a lot easier way of identifying the w3wp process.  He said just open a command prompt and type in "iisapp" and it will list all the Application Pool processes with the process ids.  I took his advice and sure enough it gave me everything I needed to choose the correct process from the Visual Studio "Attach to Process" screen.  If you don't really know what I'm talking about then below is details on how to do it.

For me there are times when I'm developing with InfoPath or SharePoint and I need to create some code (Workflows, Web parts, ...) that runs part of the w3wp process and running it in debug mode from Visual Studio is not possible and you will have to deploy the code and then attach the Visual Studio project to the w3wp process that its deployed for stepping through the code.  For example, recently I had to create a new SPD Workflow Action to send out emails with a "From Address" that can be specified and to use the SharePoint SMTP property that's set in Central Admin.  To do this I had to create a new Workflow Activity Library project and this project type can't be run in debug mode from Visual Studio (if I'm wrong about this please correct me).  To debug the code in this project you have deploy it first and then attach your Visual Studio project to the w3wp process that it runs in and then do something from SharePoint or InfoPath that will execute the deployed code.  To attach the Visual Studio project to w3wp process you can either click "Debug->Attach to Process" or "Tools->Attach to Process" menu combination and then the "Attach to Process" screen will appear.

Then you will need to select the w3wp process that your code is running in.  If you develop on a SharePoint server then you will almost always have more than one w3wp process to choose from.  This is where the "iisapp" command helps out.  If you open a command prompt and type "iisapp" then it will list all w3wp process (Application Pools) running with some details.

This list should give you enough information to choose the correct w3wp process from the "Attach to Process" screen.  Click the entry you want and then click to the "Attach" button to attach to it.  Now set your break point and then do something from SharePoint or InfoPath that will execute the code.

I'm sure this was a big repost for most people and I'm sorry for that but I just wanted to share what I learned that way it may help someone starting out with SharePoint, Workflow or InfoPath development.

Cheers

Today was one of those days when you need everything to go smooth but things don’t. The morning started out really well and I was making great time writing new code on my IBM ThinkPad T61 Vista machine and then I needed to transfer my ASP.NET 2.0 Ajax projects over to my VPC image to integrate my SharePoint custom web service and WMI code and that’s when nothing worked correctly and my day basically started to waste away. The VPC image is fairly new but I thought it was in good working condition because that’s where I had built and tested successfully an ASP.NET Web Service project but not true. When I moved over all my ASP.NET 2.0 Ajax projects and tried to open them that are when things started not to work. The first problem I had was not being able to open my projects correctly but that was an easy fix because I just installed the ASPAjaxExtSetup.msi file (ASP.NET Ajax 1.0 Extensions) but the problems that I had after that was what took so long to fix.

The projects that I copied over and opened or any ASP.NET projects created from the VPC image had the below error messages. The error messages only showed up and prevented me from compiling when I was in HTML Source view. If I was in the Design View everything would compile and publish but the only Toolbox that I had was HTML.

Error 1:

The language referenced by the Language attribute is not supported by Visual Studio IntelliSense and statement completion. Changing the language name when the file is open requires that you close and re-open the file

Error 2:

Unrecognized namespace ASP

I’ve never seen the error messages before and when I went searching the internet I couldn’t find anything that helped me solve the problem. Then I started comparing what products were installed for each Visual Studio 2005. You can do this by opening Visual Studio and then clicking Help->About Microsoft Visual Studio and looking in the Installed Products textbox. To make things easier I clicked the Copy Info button and pasted everything in notepad. After doing a little comparison I noticed that “Microsoft Visual Web Developer 2005” was installed on my Vista version but not on my VPC image but everything else looked the same except for the Vista specific patches. Since that was the only major difference I decided to install the missing product on my VPC image and 30 to 45 minutes later the install was done but now when trying to open the projects I got error message saying the projects were unsupported with the installed version. This was an easy one; I just needed to install SP1 for Microsoft Visual Studio 2005.

I found the SP1 for VS 2005 and started the installation and everything was going great and it was almost done and then a new error came up saying it ran out of virtual memory and gave me the below error message and link.

Error 1718: File name of file was rejected by digital signature policy.

http://go.microsoft.com/fwlink/?LinkId=73863

This error message seemed pretty familiar but when I looked through all my notes and blog posts I couldn’t find anything which surprised me a little because usually I write things down so I don’t have to trouble the same problem more than once. Enough about that and back to the error, I took the advice of the article and downloaded the Windows 2003 Server patch and installed it on the VPC image and then reran SP1 for VS 2005. An hour later the installation finished without any errors (hooray!) and then when I opened the projects all the errors were gone and everything appeared to be working correctly. This was a crazy mess but I’m just glad that I was able to fix it and didn't have to rebuild the VPC image.

Lesson learned for me this time around is to make sure “Microsoft Visual Web Developer 2005” gets installed when building a VPC image. I’ll remember this because I’ll be building a new one this month once Microsoft Visual Studio 2008 is officially released. I saw a demo of the product at Dev Connections and it looks really impressive and the CSS and JavaScript support looks really nice.

Hope everyone has a good weekend and if you’re in the Reston, VA area come out to the Nova code camp on Saturday, November 17^th and hang out with everyone for the day. Some of the sessions look killer and I can’t wait to attend some and speak at mine. Below is a link to the website and it has all the information that you need.

http://novacodecamp.org/

Cheers