Archive for the ‘Visual Studio’ Category

Visual Studio: Cannot Step Into WCF Service Hosted In IIS

October 25, 2010

If you are reading this then you are probably a complete newbie like myself to WCF. Never mind. We can huddle here together for warmth.

So in my case I had a WCF Service running on localhost under IIS and a Client that consumed that Service running under Cassini. There was a Breakpoint in my Client code on the call to my WCF Method and when I hit that breakpoint and hit F11 then the debugger would step into it as obediently as Frankenstein’s Monster on an assassination mission. I was as smug as a 200kg Tabby Cat locked in a Cream factory over the Christmas holidays.

My client app and my WCF app were in different solutions and open in different instances of VS2008.

Then I made my critical mistake – I went to Lunch.

During my absence tiny invisible super-intelligent Manta Rays from the Planet QUARX sabotaged my apps so that I could no longer step into the WCF code from my client. My Team Lead could not figure out why either.

Well about 96 Google Minutes later I found this hyper-simple solution (remember, we’re newbies here) on

I slavishly did what they suggested which was in the VS2008 instance hosting my WCF Solution, select Debug from the main menu and…

select process aspnet_wp.exe from the list of available processes, and click the Attach button. You will find this process attached to the debugger. Open the HelloWorldService.cs file and set a breakpoint if you haven’t done so already. Now run the HelloWorldClient program…from another Visual Studio instance…and you will see that the breakpoint is now hit.

Good news: The tiny hyper-intelligent Manta Rays are gone and the Tabby Cat is back. Pass me the Triple Fat thanks.


Visual Studio 2005 ‘Could Not Load Type Global.asax’ and ‘Cannot Copy Assembly After Build Because It Is Being Used By Another Process’ and ‘Control Name is not a member of Page Name’

May 18, 2010

Had a berserk time trying to load one of our corporate websites for the first time on a new DEV machine. It was an exemplary Journey Of Pain which I will now share with you.

The web site comprises 12 projects. Even after I loaded them down from Visual Source Safe into a solution and put in the necessary references to each other via Add Reference I still had a kaleidoscope of errors and warnings which no one here had ever seen before. My colleague performed a ‘Clean Solution’ which miraculously removed a lot of the warnings and errors.

Learning Point #1: When downloading a non-trivial solution from Visual Source Safe, do a Clean Solution after adding in all the references. There is some forum chat that says a Rebuild All will do the same thing, but I found in practice that Clean Solution cut out a lot of warnings and errors which Rebuild All did not.

I was now left with Cannot Load Type Global.asax.

Opening up the Global.asax.vb page I found some unresolved references, so I added those, then rebuilt, but still got Cannot Load Type Global.asax., A bit of Googling told me that Cannot Load Type Global.asax meant by main dll was not being generated. So I excluded Global.asax.vb from the project to see if anything was being covered up and did a rebuild.

That rebuild revealed a squillion errors. Specifically, I got a Cannot Load Type on every single one of the User Controls (ASCX files), plus cannot copy assembly after build because it is being used by another process . Googling the Cannot Copy Assembly After Build error I found that this can occur because hostingEnvironment shadowCopyBinAssemblies=”false” was set in web.config. I commented out that entry and lucked out on it working. Cannot Copy Assembly After Build was deaded.

Next thing was to add references to 3rd party DLLs required by the solution. The DLLs were not in our Source Control so i had to hunt them up on the Web. these Dlls were referenced in our Web.Config file and not directly anywhere else, but they came out as obvious errors during the build.

This left me with 96 errors along the line of Cannot Load Type whatever.ascx along with a generous sprinkling of ‘ControlName’ is not a member of ‘PageName’.

Attribute Blocks

These turned out to be sourced from the same basic issue: the aspx.designer file was not being recognised by the Code Behind file – they were not linking together as if they did not belong to the same Partial Class. Unusually the designer files were not nested below the ascx file along with the aspx.vb (code behind file). I spent ages trying to force these designer files to regenerate without flat out deleting them or converting to a Web Application Project and then hit the post by hennehelene in this ASP.NET forum thread which prescribed a weird alchemy, namely to include a CodeFile attribute to the aspx.vb file, compile then remove the CodeFile Attribute and compile again.

HenneHelene’s solution works for me because my pages had the same basic markup as hers: A CodeBehind attribute, an Inherits attribute, but no CodeFile attribute. I was thus able to add then remove the CodeFile attribute as described above, but I subsequently returned the CodeFile attribute back to the page because I didn’t want any future developer encountering the same issue.

The presence of the CodeBehind attribute without the CodeFile attribute suggests that the web site I was loading originally began life as a .NET 1.1 application

Codebehind is a .NET 1.1 Page Attribute which is retained in.NET 2.0 for backwards compatibility. CodeFile is the corresponding .NET 2.0 attribute.

Yet Another Reason Why Breakpoints Will Not Be Hit In Visual Studio: You are running Cassini.

February 24, 2010

I would imagine this is probably the most common reason why breakpoints are not hit: the Web Application is running under Cassini.

Cassini is the built-in Web Server that comes with Visual Studio 2005/2008. It’s a lightweight Web Server provided to spare you the trouble of setting up IIS on your local machine. But being lightweight it can’t do everything and one thing it cannot do is provide debug support. This ASP.NET forum post, ‘Debugging aspx hosted by Cassini’ provides some discussion on the issue.

To debug in Visual Studio when running Cassini you have to manually attach the debugger to the Cassini Process.

To paraphrase Kiliman in his forum post:

In VS.NET, it’s Debug | Processes…

Find WebDev.WebServer.exe in list of running processes and click Attach. Make sure Managed Code or Automatic is selected from the Attach To: DropDownList

If you don’t want to manually attach the debugger every time, then make your site IIS based then go to the Project Properties and change your settings from from internal webserver to IIS.

Here’s an interesting tip from an old Cassini information page for Framework Version 1.1 that allows you to Debug under Cassini without manually attaching that might still work in later Framework versions. I haven’t tried it myself yet. Basically you make Cassini the Start Application for your Debug Build Configuration and define your Web App as a Command Line Parameter.

The reason that Cassini cannot participate in Visual Studio .NET Debugging without the debugger manually attaching to the process is that Visual Studio Debug Builds send a special (non-standard) HTTP Request to the Server using the DEBUG Verb called a Debug HTTP Request. IIS knows how to handle Debug HTTP Requests but Cassini does not.

The DEBUG Verb is used by IIS to verify that the process of the application is running and to automatically select the correct process to attach the Visual Studio debugger to. Its a non-standard HTTP Verb invented by Microsoft for its own purposes, that’s why generic Web Servers like Cassini don’t handle it. See Stack Overflow here.

Cannot Drag Additional Table From Server Explorer Into Existing DataSet (.xsd) Failed to add TableAdapter.

December 8, 2009

Just a short one here,…

I have a very complicated DataSet (.xsd) file and our schema is being updated. I needed to drag a couple of new tables from the ServerExplorer into the DataSet Designer…but Visual Studio wouldn’t let me do it. I just got the ‘ghostbusters’ icon and the table would not drop.

Trying to work around the issue, I did right-click on Designer Add->TableAdapter and configured the Adapter but when clicking ‘Finish’ I got the error ‘Failed to add TableAdapter’ along with the SQL Named Pipes Provider error 40.

For half an hour I toyed with hand-coding the necessary table and all associated ADO.NET code directly into the DataSet designer file. Fortunately this madness subsided.

Then I created a new DataSet and copied/pasted the old DataSet from the Designer into the new one. This worked. No Named Pipes errors AND I was able to drag new tables into the Designer for the new DataSet. But this was all just a Journey Of Pain. I should be able to simply edit the existing DataSet. I threw a brick through the monitor and went home for a relaxing session of concreting the hamster (also here) to let my right-brain work on the problem unencumbered by reason.

Well today’s a new day and since it was my last straw, what I did was rebind the Project to Visual Source Safe. I had unbound the Project from Soure Control a little earlier for weird reasons I will keep to myself. Once I rebound the Project to Source Control via File -> Source Control -> Change Source Control I was able to add the new table to the Dataset. This was so stupidly illogical that it did not surprise me in the least.

Once day I will be able to explain why this makes any difference but today I can’t. But if you’re in a similar position why not try rebinding the Source Control? It worked for me and now I’m a multi-millionaire with a full head of hair and a tremendously loyal concrete hamster. Buy one today.

Random Thought 20-Jan-2011
Maybe rebinding the Project to Source Control make the .xsd files writable. Perhaps they had become unwritable when I unbound?

Visual Studio 2008 Disappears From Screen When Loading Solution or Project

November 5, 2009

I started up Visual Studio 2008 and clicked on my Solution file AmazingSolution on the Start Page. Visual Studio started dragging up the solution and was just loading up a XAML file when it disappeared. Just disappeared.

This was about as expected as a nasty case of Sponteneous Combustion. Alice In Wonderland is one of my favourite books but when Visual Studio starts behaving like the Chesire Cat it’s a little perturbing…more so since I had just hacked the Registry to overcome the issue of Intellisense not appearing in XAML files after installation of Windows SDK.

My terror was complete. I had destroyed Visual Studio.

The paramedics were called, the Emergency Sacrifical Ferret put on stand-by and I ran a repair on Visual Studio, as Microsoft Connect recommended.

Then I rebooted, restarted Visual Studio and loaded AmazingProject. Visual Studio disappeared again. I slaughtered the Ferret and ordered a crate of Vodka in celebration of my impending sacking, but then checked the Event Logs. Glory! It contained a very useful entry:

.NET Runtime version 2.0.50727.3603 – Fatal Execution Engine Error (7A036050) (80131506)

and Googling that showed that Microsoft Connect have patch files for that very issue…Well, it was too late for the Ferret, but I HADN”T DESTROYED VISUAL STUDIO AFTER ALL!

To Summarize

1. The horrifying sudden disappearance of Visual Studio 2008 can be caused by a bug relating to the loading of XAML files. Check your Event Logs and if you see .NET Runtime version 2.0.50727.3603 – Fatal Execution Engine Error get the patch from Microsoft Connect at the link above. No Ferrets need to be slaughtered.

2. The unrelated problem of Intellisense disappearing from XAML files is caused by installing a Windows SDK after (on top of) Visual Studio 2008. This overwrites the registry key VS uses to locate the XAML Intellisense file. To fix that, run a Repair on Visual Studio 2008 or, if you’re feeling brave, hack the registry.

So What Happened To You ?

Sick of having no Intellisense in XAML I Googled the registry hack. At the same time I did a ‘Close All But Me’ in Visual Studio on a XAML file then closed Visual Studio. I then restarted Visual Studio to allow the registry hack to take effect, whereupon it did the Chesire Cat on me. It was simply a malevolent coincidence…perhaps a warning never to do a registry hack when a more polite known fix exists 🙂 (In this case the Visual Studio Repair.

Hey Bruce, chuck us another Ferret will ya ?

VB.NET ‘Type or Namespace cannot be found.’ after converting VS 2005 projects into VS 2008

October 23, 2009

I am converting some VB.NET projects from VS 2005 into VS 2008. I had converted the projects ‘Animals’ and ‘Food’, put them into a Solution, Zoo.sln, added a Project Reference for Food into the Animals project and compiled the Solution which duly compiled and ran.

Visual Studio 2008 Conversion Report Ambiguous
But, examining the Conversion Report for ‘Food’, I noticed that only the Food.vbproj file was marked as converted. The summary at the end of the log said:

Converted: 1 file.
Not Converted: 72 files.

This made me worried. Why were there 72 files Not Converted ? Had I actually converted Food properly ? Angst got the better of me, so I Unloaded and Removed Food from Zoo.sln, retrieved the source again from Visual Source Safe and reconverted the Project.

I got the same result: 1 file converted (just the vbproj) and 72 files with no status next to them (but no errors either) and a count of 72 ‘Not Converted’.

I Googled here and there and eventually found a forum post by the knowledgable Peter Bromberg which said that Class files (.vb and .cs) will not by touched by the VS 2005 to VS 2008 Conversion. That put me at ease. So then I re-added Food to Zoo.sln, added the Project Reference into Animals as before and recompiled.

This time 102 errors: Horrific memories of school examinations covered in red pen filled my mind.

All the errors said the same thing: ‘Type or Namespace xyz cannot be found. (Are you missing an Imports or Assembly Reference) ?‘ All the errors were in ‘Anmals’ referring to unknown types which I knew existed in ‘Food’.

Well, I checked the Project Properties for ‘Animals’ and the Reference to Food ws there and it was to the correct Food.dll. I removed the reference, recompiled Food and re-added the Reference. Still 102 errors. Things hadn’t looked this grim since the days I flunked MacroEconomics 2A with a score so low it had to be examined through a microscope.

Prodding The Corpse

Here was a typical line returning two unknown type errors on MonkeyDrink:
Dim fermentedCoconut As MonkeyDrink = New MonkeyDrink()

As an experiment I tried the following:
Dim fermentedCoconut As Food.MonkeyDrink = New Food.MonkeyDrink()

To my amazement, Food.MonkeyDrink appeared in Intellisense and resolved to a known type, reducing my error count. So Animals obviously had a valid Reference to Food. Why then the compile error ?

Now you’re probably thinking ‘the dolt has left out his Import statements in the class files’ but remember these projects were converted – they never had Imports statements in them in the first place, yet Animals had always compiled with Food before. WHY was it chucking a spaz now ? The pain, the pain, the journey of pain…

Unknown Feature #999

Checking again the References Tab in the Property Page for the Animals Project, I clicked on Food in the References list then scrolled further down and noticed for the first time a pick list of namespaces from all the Referenced projects: Lo and Behold, Food was not selected. Once I selected Food (thus telling the compiler to Import all the Namespaces from Food) and recompiled, my errors vanished with the silken ease of Master Ninjas after a successful assassination.

The miraculous feature I had discovered is the Visual Studio Imported Namespaces List which MSDN beautifully describes here

The Imported Namespaces List is only available in VB Projects (not C#), that’s why I had never seen it before.

So Now I Know

If your Types cannot be found in your VB.NET project but you know the containing project is referenced, or maybe you’re wondering why your Class files have absolutely NO Imports statements in them, have a look at the Imported Namespaces List in the Project Designer via Project Properties. It’s….how you say…verrrrry nice.