Enterprise Library 4.1 - unit test don't work

by 2. March 2009 08:13

Note: Run the "Install Instrumentation" menu option from the Microsoft Patterns and Practices menu or the Unit Test will fail during [TestInitialize] method. 

When first attempting to run Unit Test for Enterprise Library 4.1, I was greeted with the following message (other times it would just hang - VS would go Not Responding): 

Although I have an x64, Intel Core 2 Duo CPU T5750 @ 2.00Ghz system with 4 Gig RAM I also recognized a large number of Unit Test in the solution so I unloaded the following projects

Keeping only the projects I'm currently interested in loaded (reflected by curved arrow above).

Now my Unit Test would actually run but I was greeted with an odd (unexpected) error:

What was odd about this error message was that the current assembly shows "Logging" and the error message complains that it can't load "Logging"; odd that it was complaining that it couldn't load itself.

The key to this error was the PublickeyToken - the current running assembly (project) shows a PublicKeyToken=null where the error has an actual token.  Something was attempting to load a different assembly of the same name but from a .DLL (not project).  

The next step was to locate the offending process - in this case it was the reader that was complaining so as I examined it's value I noted the "RollingFlatFileTraceListenerData".   Running a global search for this class (more specifically - within a .Config file) resulted in the following:

The configuration file was requesting a specific .DLL where our Unit Test has a reference to the actual project - two different .DLLs.

The fix was to remove everything after the Assembly name as shown below - this will allow it to default to the project being used by the Unit Test.

Be sure to rebuild your solution before attempting to run the Unit Test after updating the .Config file.

After complying with the above steps I was able to run the above referenced Unit Test and it passed. 


Do a solution search and replace for the for the following (without the quotes):
", Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

After the above search and replace you'll find that we're down to 37 failures; many associated with the Performance Counter.

 To be continued...


Note: I use Visual Studio 2008 Professional Edition

Javascript debugging doesn't work in Visual Studio 2008 - or does it?

by 6. January 2009 09:36

We need to have Crystal Reports support in Silverlight - an adventure I begin this evening...   I started with the HTML BROWSER INTEGRATION tutorial and plan to have a Silverlight event execute a javascript method to open a new window (providing the necessary parameters) for launching our Crystal Report.

The head-banging session started rather early in the game for less than obvious reasons - I couldn't get a breakpoint to work in my Javascript code - they were being ignored :O

Googling "Visual Studio 2008 Javascript" revealed some pretty cool blogs and webcast suggesting it is a plug'n play so obviously it was something on my machine???  No, so there seems to be a bug...

In all my configuration changes (Debug options as well as project) I didn't think to turn off Silverlight (arrow below) because I need to debug my Silverlight application into the Javascript call HOWEVER!  When I turned this off (unchecked it) I was now successfully debugging my Javascript code as advertised.


Seems like an XOR situation; I can either have Silverlight or Javascript debugging but not both....   

I submitted a bug report to Microsoft on the issue so if they are consistent I should have a response within a relatively short period of time letting me know if this is a BUG or FEATURE ;)


LINQPad - debugging imported DLLs in Vista environment

by 21. September 2008 23:03

In an earlier BLOG I show how extensible LINQPad is.  I encountered an odd behavior when attempting to attach to LINQPad while debugging from my Vista box.  It didn't work; at least not directly (works great from my XP box at work).

Oddly, the behavior under Vista, when the following steps are not complied with, is that the Visual Studio Debugger treats LINQPad like a Web application; a Script Documents folder appears and there will be two scripts shown.   The scripts contain the HTML contents of the top and bottom LINQPad windows and my breakpoints in code are not respected.

The work-around requires me to follow these steps - when complied with I can consistently step into my code.

  1. With Visual Studio 2008 opened set my breakpoint
  2. Launch LINQPad and open script (do not run)
  3. In Visual Studio
    • Click on Debug
    • Attach to process
    • Select LINQPad
    • Click Attach button
    • The breakpoint in Visual Studio will complain (won't be solid circle)
  4. Switch back to LINQPad and run script.  For the duration of the attached debugging session debugging will work.  Once you stop debugging you'll have to exit LINQPad and start over from step 2 above.

Note: I thought perhaps the problem was that I hadn't yet installed Visual Studio SP1 (long process) so I installed it and have the same behavior. 


SharePoint - Configuration for debugging

by 28. August 2008 12:59

Configuring SharePoint for Debugging was quite the adventure, particularly since you have to sift through tons of information on the topic...   I have two different ways that do work (both relatively easy); I'll provide the details below.

The following screen is what started the adventure:

From Visual Studio 2008 I clicked on Debug, Attach to Process and sorted by process - I found I had two w3wp.exe processes; I need to attach to one of them.  I should note that my Google research resulted in varying ideas on the topic, one site I read noted that if you select more than one process *only the first will run*; if the first isn't yours then it won't work, most sites will have you locate the applicable ID using IISApp.vbs, which was not to be found on my system - I later learned it is an IIS 6 file (more on this below).   The SharePoint Training Management Application Documentation notes that you should select them all - indicating that they will all be debugged (which makes sense).   But just in case.... below is the steps to run your specific process.

I clicked on Start and typed in CMD

From the command prompt I did the following:

cd \Windows\System32\Inetsrv

appcmd list wps

I found that I needed to attach to w3wp.exe with ID 3856.  Note AppCmd.exe is used with IIS 7.0, I understand that with IIS 6.0 you'll have to use the following:
cscript c:\windows\system32\iisapp.vbs /a "SharePointDefaultAppPool" /r

I deleted the Training*.* files from C:\Windows\Assembly (GAC), attached to process 3856 and ran the site to see what would blow up - I got the following error: 

I used this opportunity to find where the Bin folder was by getting a reference to the context (see image below on line 38)

Note above that I got past the error  - it was because I added the following statement to all of the projects that need to be in the GAC - after a successful build the DLL files would be copied to the Bin folder for the site:

However, I was being stopped by a different Error:

At first I thought I'd take the easy route, all the research on CASPOL (much of which hasn't worked for me in the past) wasn't a path I have the time to take and I was the only developer placing code on my server (I'm rationalizing because I know this isn't the right way).  I changed the Web.Config to use "Full Trust" as shown below so I wouldn't have to deal with Partial Trust:

As well as it was working (breakpoints being hit) I was not happy with the Full Trust and Bin folder solution.  I deleted the files from the Bin folder, set trust back to WSS_Minimal and updated my Post-Build events as follows - Note: the colon on the first column of the second line is a REMARK statement (line is ignored); the first line installs my DLL into the GAC.  I did this for each Project that needed to be in the GAC

I then complied with the following steps:

1.  Compiled all of the projects (post-build updated GAC)
2.  Deployed the applicable sites
3.  Clicked Start | Command => IISRESET / RESTART
4.  Attached to the W3wp.exe process
5.  Loaded the site and all of my breakpoints were hit - everytime I accessed the page

Debugging worked as well with the files in the GAC and partial trust as they did with the files in the Bin folder w/Full trust.

Note: I didn't have to put my .PDB files in the GAC (many sites suggest this)

Something worth noting is that during my Google Adventure to Debug SharePoint I ran into something that said if you went to Tools | Options and unchecked "Enable Just My Code (Managed only)" that this was all that was required.  At the time I tried this it worked but as you see below it is currently checked and it is still working.  Just in case it could make a difference I'll note it here.

Disclaimer: I develop on Windows Server 2008, .NET 3.5 SP1, Visual Studio 2008 - don't know how well these tips will work in other environments.



Blog videos and references to CodePlex projects are no longer valid