Unable to step into the CSLA.NET (Csla.dll) source code while debugging ProjectTracker sample app in VS 2005

Unable to step into the CSLA.NET (Csla.dll) source code while debugging ProjectTracker sample app in VS 2005

Old forum URL: forums.lhotka.net/forums/t/2070.aspx

shashisatya posted on Wednesday, January 03, 2007

Have a strange problem. I am unable to step into the CSLA.NET source code while debugging the ProjectTracker sample application. Have been struggling because of this as I am unable to look into the source code of CSLA.NET and find out what's happening behind the scenes. All the necessary assemblies are referenced and the Csla.dll is referenced as a file. Have the same issue on the other app which I have developed implementing CSLA. NET.

But everything works fine on my colleague's machine and she is able to step into the source code of CSLA.NET. Why? Does it have something to do the settings of VS 2005 on my machine and could there be a problem with the way the assemblies are referenced in the application?  I am running the app with the default settings, haven't made any changes.

Any ideas out there? Any help would be appreciated.

Thanks in advance.

ajj3085 replied on Wednesday, January 03, 2007

When running, try going to Debug -> Windows -> Modules.  Find Csla and right click and tell it to load module.  You'll have to locate the pdf file for Csla.  You'll then be asked to locate the source code.

HTH
Andy

shashisatya replied on Thursday, January 04, 2007

Thank you Andy.

I could fix the issue. Unfortunately, I registered the Csla.dll in the GAC, had it referenced from the bin folder of CSLA. So, the client app referencing it could not load its symbols as it was no longer user code and could not somehow locate its .pdb file.

Things got back to normal once I had removed it from the GAC and could notice that the symbols were loaded for the Csla.dll in the Modules window of VS 2005.

The Modules window has been very helpful. Could not understand why Csla.dll was strongly named and not optimized by default? May be only for deployment scenarios, not for development scenarios.

Andy, I have another question. Why does the TransactionalDataPortal transactions get elevated to DTC transactions even if the connections are targetting the same database? Is there workaround for this and should we pass the connection from the editable root object to the editable child objects (as in the Resource object of ProjectTracker app)?


ajj3085 replied on Thursday, January 04, 2007

shashisatya:
I could fix the issue. Unfortunately, I registered the Csla.dll in the GAC, had it referenced from the bin folder of CSLA. So, the client app referencing it could not load its symbols as it was no longer user code and could not somehow locate its .pdb file.


Ahh.  Putting Csla into the GAC really isn't recommended, and you found one of the reasons why.

shashisatya:
The Modules window has been very helpful. Could not understand why Csla.dll was strongly named and not optimized by default? May be only for deployment scenarios, not for development scenarios.


You can sign an assembly built in Debug mode, which will cause it not to have any optimizations.

shashisatya:
Andy, I have another question. Why does the TransactionalDataPortal transactions get elevated to DTC transactions even if the connections are targetting the same database? Is there workaround for this and should we pass the connection from the editable root object to the editable child objects (as in the Resource object of ProjectTracker app)?


This is a sillyness MS left us with.  If you open more than one connection within the TS, even if its with the exact same connection string, the transaction gets promoted.  The solution is to use the same connection within the scope and Sql Server 2005.  I think in Sql Server 2000 it will always promote, and I'm not sure there's a way around it.

shashisatya replied on Thursday, January 04, 2007

Thanks for the reply, Andy.

Another question... can you tell me something about the Active Objects and their objective? Am I going to get any performance benefits by using Active Objects in conjunction with CSLA.NET?

Also, would like to know what are advantages and disadvantages of using BindingSource controls in a n-tier app with a Windows app as the UI? I see that people (atleast in our organization) are against using these controls which act as a bridge between your data-bound controls and datasources. Since I am new to Windows Forms development, I could not think of an immediate reason. Rocky makes good use of these BindingSoiurce controls in the ProjectTracker sample app and I see that these controls are very powerful.

Have also noticed that even in ASP.NET development, some developers are against using the datasource controls (SqlDataSource, XmlDataSource etc.) in multi-tier apps. They would rather go with Datasets or objects. Does it have some thing to do with the memory usage or some other problems. Or the developers scared of all the unwanted API an features that comes along with these controls?

Any light on my way would surely be appreciated.



Copyright (c) Marimer LLC