Entlib5 Weirdness When Debugging

Topics: Data Access Application Block, Enterprise Library Core, General discussion
Sep 16, 2010 at 3:05 AM

Hi,

I'm trying to upgrade my DAL to use Entlib5 and I'm encountering weirdness when stepping through in the debugger. At this line:

this.database = EnterpriseLibraryContainer.Current.GetInstance<Database>();

The code jumps to Microsoft.Practices.ServiceLocation.ServiceLocatorImplBase.GetInstance<TService>() and shows a load of stuff like:

--- c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocatorImplBase.cs 
00000000  push        ebp  
00000001  mov         ebp,esp 
00000003  sub         esp,1Ch 
00000006  mov         dword ptr [ebp-10h],ecx 
00000009  mov         dword ptr [ebp-4],edx 
0000000c  cmp         dword ptr ds:[045C2C4Ch],0 
00000013  je          0000001A 
00000015  call        5CE663C9 
0000001a  mov         eax,dword ptr [ebp-4]

It also tries to open up the source code file in Notepad, which then crashes according to Event Viewer (!).

Then I "step out" and get:

                this.database = EnterpriseLibraryContainer.Current.GetInstance();
00000036  mov         eax,dword ptr [ebp-3Ch] 
00000039  mov         dword ptr [ebp-44h],eax 
0000003c  call        dword ptr ds:[045C69F8h] 
00000042  mov         dword ptr [ebp-48h],eax 
00000045  push        45C72B0h 
0000004a  mov         ecx,dword ptr [ebp-48h] 
0000004d  mov         edx,45C6BBCh 
00000052  call        5F6A0FE1 
00000057  mov         dword ptr [ebp-4Ch],eax 
0000005a  mov         ecx,dword ptr [ebp-48h] 
0000005d  call        dword ptr [ebp-4Ch] 
00000060  mov         dword ptr [ebp-50h],eax 
00000063  mov         edx,dword ptr [ebp-44h] 
00000066  mov         eax,dword ptr [ebp-50h] 
00000069  lea         edx,[edx+4] 
0000006c  call        5F542618 
            }

And once more for:

            this.CreateDatabase();
0000002e  mov         ecx,dword ptr [ebp-3Ch] 
00000031  call        FF0FBA18 
00000036  nop    

That's not right!!! What is going "wrong" please?

If I just run the web app, everything works fine.

Richard

Sep 16, 2010 at 4:34 AM

Were you pressing F11 when you get to that line of code?  If yes, why do you need to step inside that code if everything works fine?

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Sep 16, 2010 at 6:09 AM

Yes, I was stepping through the code line by line as you might.

This is to verify that the database is really being created (so hovering over the values, etc. to ensure all is well).

Why should that produce the behaviour above? It certainly doesn't for every other .Net app I've built in the last n years including Entlib 4.1...

If all is well, execution should proceed past to whatever line of code or curly brace is next, not "00000000  push        ebp".

Richard

Sep 16, 2010 at 6:55 AM
Edited Sep 16, 2010 at 7:08 AM

The behavior you want is that simple if you're directly referencing the project containing the source code.  In your case, you have an assembly reference and stepping through its code requires you to have the PDB files.  However, as of now,  EntLib 5.0's PDB files is not yet been released.  

BTW,  in addition to EntLib PDB files, you might also need the PDB files of the ServiceLocator assembly which can be downloaded here.  I'm not sure if it will automatically step into EntLib's source code and skip those from the ServiceLocator assembly in the case you don't have the latter's PDBs.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Sep 16, 2010 at 9:51 AM

"However, as of now,  EntLib 5.0's PDB files is not yet been released."

Not true.

The Entlib 5.0 pdb files are included in the bin directory when you install. There's no separate download for them because they're "in the box" now.

 

Sep 16, 2010 at 9:55 AM
Edited Sep 16, 2010 at 9:58 AM

Sorry bout that, I was used to the previous versions where it is not included in the installation folder and available as a separate download.

Richard,

In case you need instruction on how to use PDB files, here's a thread with steps on how to use it to debug the source code.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Sep 17, 2010 at 2:00 AM

Hi, thanks for the feedback.

I think I haven't communicated my point properly though.

I don't want to see pdb stuff, funny codes, whatever. When I F11, I want my debugger to step over that part as it would for any other call to a referenced DLL (including the create database call to Entlib 4.1 DAB), staying in my code.

That make sense?

Richard

Sep 17, 2010 at 7:05 AM

Hi Richard,

Sorry if we may have missed or may still missing something here, but it looks to me that what you would want is to be able to step into the enterprise library code while debugging your app. As mentioned also by my colleague a way to do this is to use Entlib's PDB file in the case you're not directly referencing the Entlib App Block projects. Does the PDB approach doesn't work for you? If not, then how about directly referencing from the EntLib App Block project (DAAB) instead.  Hope this somehow helps.

Gino Terrado
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Oct 11, 2010 at 5:28 AM
Edited Oct 11, 2010 at 5:29 AM

Hi, sorry for the delay in replying. I'm not interested in stepping into the blocks in any way. I trust what happens there :)

In 4.1, if I'm stepping through in debug, when I would hit the point where (say) I create the database, it would just step over. Now, the debugger steps into disassembly.

In solution properties debugging options, there are a list of files that should be ignored under "Do not look for these source files":

e:\Builds\EntLib\Latest\Source\Blocks\Common\Src\Configuration\ContainerModel\Unity\UnityContainerConfigurator.cs
e:\Builds\EntLib\Latest\Source\Blocks\ExceptionHandling\Src\ExceptionHandling\ExceptionPolicy.cserConfigurator.cs
c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocatorImplBase.cs.cs
e:\Builds\EntLib\Latest\Source\Blocks\Caching\Src\Caching\CacheFactory.csiceLocation\ServiceLocatorImplBase.cs.cs

BUT, the debugger steps right into "c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocatorImplBase.cs.cs" disassembly.

A bug? You can recreate the issue by stepping into code like this:

Database database = EnterpriseLibraryContainer.Current.GetInstance<Database>();

 

Like I say, in 4.1 it'll just step right on over it but not in 5. I can turn off the disassemby stuff like this:

Tools -> Options -> Debugging -> General -> Unmark Enable address level debug to disable this feature.

But this will result in a message when stepping through:

"There is no source code available for the current location" (obviously)

Hope that makes some sort of mad sense!

Richard

Oct 11, 2010 at 6:37 AM
Edited Oct 11, 2010 at 7:00 AM

I see what you mean.  I don't believe though that this is a bug in EntLib as this has something to do with how Visual Studio works.  In addition, you're probably not encountering that in 4.1 because the ServiceLocation assembly is not yet being used in the EntLib source code then.  I'm still trying to figure out if we're doing the correct Debugging settings (or you could get a faster answer on this over Visual Studio forums) but a way around this would be to create a separate location of the Enterprise Library pdbs and not including the pdb file for Microsoft.Practices.ServiceLocation.  Additionally, if you don't have the source code for Unity, you might also want to remove pdb files for Unity-related assemblies.   Make sure to update the location of the pdb files in Tools -> Options -> Debugging -> Symbols.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Dec 3, 2010 at 1:29 AM
Edited Dec 3, 2010 at 1:38 AM

I'm bumping this. If you look at this simple console app:

namespace Console
{
    using System;
    using Microsoft.Practices.EnterpriseLibrary.Validation;
    using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

    class Program
    {
        static void Main()
        {
            var test = new Test("Ric");

            Console.WriteLine(test.Validate());

            Console.ReadLine();
        }
    }

    [HasSelfValidation]
    class Test
    {
        public Test(string name)
        {
            this.Name = name;
        }

        [StringLengthValidatorAttribute(5, 100)]
        public string Name { get; set; }

        [SelfValidation]
        public bool Validate()
        {
            var validationResults = Validation.Validate(this);

            return validationResults.IsValid;
        }
    }
}

If you reference the appropriate entlib 5 blocks, you get the "No source code is available for this location". VS2008, 2010, doesn't matter. Execution is basically "stuck" here. Totally useless.

There are pdb files in the obj / debug folders but I don't think that is something to focus on.

Why do we not see the same behaviour in 4 vs 5? What changed? Why do we now get attempts to load a pure source file when debugging? If you think this is normal bahaviour, why didn't we see it before? Why don't we see it for every other 3rd party dll we use (e.g. Telerik)?

Something is wrong somewhere. Upgrading to 5 from 4 should not introduce this sort of "functionality". Sure, I can avoid this by stepping over but its easy to miss if I want to look at one line, then the third and a reference to one of the blocks is called in the second. It's bloody annoying, let me tell you! :)

Richard

 

Set a breakpoint on: var validationResults = new ValidationResults();

Now, if you reference the appropriate 4.1 entlib blocks and start the debugger, F11 "Step Into" will just proceed to the next line ("var test = new Test("Ric");")

Dec 3, 2010 at 2:12 AM

Pardon me for the misinterpretation.  I get it and I think this behavior is due to the fact that the PDB files are now in the same folder as where the actual entlib assemblies are.  This causes the PDBs to be copied to the project's output folder and the debugger attempts to load the source code.

There's probably a setting in the Visual Studio debugging options to workaround this behavior.  I'll see if I can find out what that is or you could also post the question to the Visual Studio forum in MSDN.

 

Sarah Urmeneta
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com

Dec 8, 2010 at 12:19 AM

Hi, I hacked up a solution.

In folder:

C:\Program Files\Microsoft Enterprise Library 5.0\Bin

I moved *.pdb into a child folder called PDB.

Ater this, debugging my project no longer resulted in the code stepping into the Entlib blocks (hooray!). There are some (I think) associated exceptions picked up in Intellitrace but I can live with that.

Thanks for pointing me in the right direction even if my fix is probably not good practice. Maybe the Entlib team can think about this feature of Entlib 5?

Richard

Dec 8, 2010 at 4:09 AM

For any feature request or verified bugs on EntLib you can logged this in the issue tracker to notify microsoft team of what added functionality/defect the users of entlib needs. HTH

Gino Terrado
Global Technologies and Solutions
Avanade, Inc.
entlib.support@avanade.com

Jun 2, 2011 at 8:33 PM

My God!

TKS GUYS!!!  I was crazy about this!!! I removed *.pdb from machine and all works fine!!

Osmar Malheiros

Sep 16, 2011 at 4:32 PM
VirtualRichard wrote:

Hi, I hacked up a solution.

In folder:

C:\Program Files\Microsoft Enterprise Library 5.0\Bin

I moved *.pdb into a child folder called PDB.

Ater this, debugging my project no longer resulted in the code stepping into the Entlib blocks (hooray!). There are some (I think) associated exceptions picked up in Intellitrace but I can live with that.

Thanks for pointing me in the right direction even if my fix is probably not good practice. Maybe the Entlib team can think about this feature of Entlib 5?

Richard


This worked for me too.  Thanks Richard!

Feb 20, 2012 at 2:07 AM
VirtualRichard wrote:

Hi, I hacked up a solution.

In folder:

C:\Program Files\Microsoft Enterprise Library 5.0\Bin

I moved *.pdb into a child folder called PDB.

Ater this, debugging my project no longer resulted in the code stepping into the Entlib blocks (hooray!). There are some (I think) associated exceptions picked up in Intellitrace but I can live with that.

Thanks for pointing me in the right direction even if my fix is probably not good practice. Maybe the Entlib team can think about this feature of Entlib 5?

Richard

Worked for me also, thanks Richard.