Since no one here appearently doesn't know anything about debugging in VS2005 I thought I might a swell share my findings to this isssue.
First; debugging a normal Website made up of regular ASPX pages is fairly simple when you're working in your local host, just press F5 in VS and a new browser windows opens...
As soon as the execution stumbles into a bug/error the window focus is moved to VS where you can step through your code, one line at the time, to see what values are set to your objects.
When your working with a so called
''3-Tier'' architecture it gets a bit more complicated.
(See below for an explanation of ''3-Tier Architecture'')Since errors/exceptions are cooped with in their own layer, they never ''bubbles'' up to the surface as they do if the error occurs in a normal ASPX page. Therefore you can't rely on the .Net error messages or umbraco's
?umbDebugShowTrace=true functionality.
This is what you can do:
In the
Debug menu in Visual Studio select ''Attach to process'' and select your
aspbet_wp process (this is the .Net Working Process that handles the execution of .Net tasks).
Then you browse your web application and as soon as an error occurs, the executions pauses and VS takes the focus in a superb manner and shows you exactly what went wrong and where. From here your able to follow every step in your code to see exactly what is happening.
This debugging capabilities is one of the main reasons I can't live without Visual Studio ;)
What a long posting this became! ;) Anyway I hope someone finds any goodies in here...
// ;) Kalle
What's a 3-Tier Architecture?In a 3-Tier environment you separate your application into 3 parts or ''layers'':
1. Presentation LayerThis is the 'frontend' our 'end-user GUI', the code here mainly interacts with the user and the form elements, the logic included here is of the type ''if the user presses 'Button A' then hide these input boxes'' etc, in the presentation layer you don't define any Classes of your own, you mainly uses the classes defined in the ''
Business Logic Layer''.
2. Business Logic LayerThe Business Logic contains your 'Business Objects', that is your namespace and class definitions. You
never insert ny SQL commands in the business layer, you simply pass them on to the Data Layer, in the Business Layer you tkae scare of the data and eventually passes it to the Presentation Layer for user interaction.
3. Data LayerThe Data Layer is the doorway to your storage (database, filesystem etc..).
The Data Layer handles requests/input from the Business Layer and passes them on to the database/storage.
Does it sound complicated to you?I guess so, to me it was until I realized all the benefits with this kind of application design.
Firstly, your Interface Programmers never needs to know anything about the underlaying database structure, wich makes his/her work much easier as they only need to know your Business Objects and what they can do.
Secondly, your Business Object developers only needs to know the interface defined by the Data Layer, ie What can be done via the Data Access interface (In my case I didn't go all the way, I just defined my datalayer in a separate class structure). Another advantage with this ''Business Layer <-> Data Layer'' separation is that you can switch database/storage anytime you have the time to rewrite your Data Layer to match say MySQL or Oracle databases.
This DB switch is far more complicated if you have your SQL statements scattered across all levels of your application...
" - Yeah I'd like to share your point of view, as long as it's my view too... (
http://www.d-a-d.dk/lyrics/pointofview)