Dot Net Technologies -- MS Tech talk and more - Debugging

New features of VS2010 which have me smiling (Part 2)

Sat, 07 Nov 2009 03:45:19 GMT

Session compression – For out-of-process session maintenance, the session state is compressed using the System.IO.Compression.GZipStream class. It also looks like it will only do this when CPU cycles are available (but I need to investigate this further). If that’s the case, you might want to set up some Performance indicators or alerts when it’s not being compressed because that might indicate further problems.

Link: <http://www.asp.net/learn/whitepapers/aspnet4/default.aspx>

Multi-Targeting – I’ve mentioned this before, but it allows you to specify which .Net version you are writing for in the VS2010 IDE. This expands the support that VS2008 has by adaptively changing the IDE to the targeted environment. The IDE adjusts its Intellisense and compilation towards the targeted version. The whitepaper indicates ASP.Net, so I need to test and see if it applies to WPF and WinForm as well. Some features:

Specified in the .config file, defaults to 4.0 when not specified.
Compiles the code to the
Intellisense adapts to the current version of the framework selected

Link: <http://www.asp.net/learn/whitepapers/aspnet4/default.aspx>

Link: http://weblogs.asp.net/scottgu/archive/2009/08/27/multi-targeting-support-vs-2010-and-net-4-series.aspx

Script Loading – The AJAX library includes the ability to have better control of script loading in .Net 4.0. It loads the scripts automatically, and in the order needed. From the whitepaper, here’s the features:

· Automatically loads all resources that are required by a script.

· Makes sure that each script is loaded only once.

· Improves performance by loading scripts in parallel and by combining scripts.

· Supports loading scripts only when they are needed (“lazy loading”).

· Supports loading third-party scripts like jQuery and your own scripts.

· Supports loading scripts from the Microsoft Ajax Content Delivery Network

One of the client features is the Sys.require. When a component and a function is provided, the callback function is called when the scripts are done loading.

Link: <http://www.asp.net/learn/whitepapers/aspnet4/default.aspx>

jQuery integration – Speaking of jQuery, it’s now included as part of the ASP.Net Web forms and the MVC project.

Link: <http://www.asp.net/learn/whitepapers/aspnet4/default.aspx>

ClientID changes – I am mixed about this one, simply because once In understood how ASP.Net set its clientIDs upon rendering, I could generate my script accordingly in my code behind. However, it’s been simplified in VS2010 to allow the user to have control over setting the client IDs. Be forewarned though, this could open you up to naming issues within container controls as such. Regardless, I am always supportive of giving the developer the option of more control. There’s a new property at the configuration file, page and control level called ClientIDMode which has the following settings:

AutoID – mimics the previous version naming scheme
Static – This specifies that the ClientID value will be the same as the ID without concatenating the IDs of parent naming containers.
Predictable – useful for controls which will be generated in template controls
Inherit – take the setting of the parent control (lots of this in VS2010, which is great, since I have been a champion for UI inheritance and control-centric programming).

Link: <http://www.asp.net/learn/whitepapers/aspnet4/default.aspx>

Improved “Add Reference” functionality – Over the past couple of days, I found myself converting a project from VS2005 to VS2008. As a result, I found myself needing to change some references as well as I changed some of the related projects. This change in VS2008 is sort of a “nice to have”. While it’s not a big win, it’s still nice as it can get painful at times changing the references. Here are the changes with this:

The .Net and COM tabs are loaded asynchronously
Defaults opening to the project tab (I find myself using this a LOT anyways, but would have preferred this to start at the “Browse” tab, or better, consider this like a MRU action and remember where I was last time)

Link: <http://weblogs.asp.net/scottgu/archive/2009/10/29/add-reference-dialog-improvements-vs-2010-and-net-4-0-series.aspx>

UML Support! Visual Studio 2010 will support the creation of UML diagrams via a modeling project. I like Visio and all, but I look forward to being able to create UML diagrams right from the same IDE I develop in. As of now, there’s no code generation support. I do think a clever developer could possible do some code generation from the saved file via CodeSmith or IDE programming, so I bet we’ll see something like that soon if Microsoft doesn’t provide it first. Check out the link below and you can see some of the functionality.

Link: http://weblogs.asp.net/gunnarpeipman/archive/2009/11/04/visual-studio-2010-uml-modeling-projects.aspx

Although available in v3.5, VS2010/v4 will have the chart control integrated into it. In the past, your options were a third-party control for charting or to use Interop and Excel, or writing your own charting libraries (gulp!). The link below lists some details on this impressive charting library if you’ve never used it.

Link: http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx

Developers will have more deployment options Web application

Get it here: http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

Tip of the Day: Redirecting page trace output to a file

Fri, 25 Sep 2009 05:11:05 GMT

If you'd like to redirect your page trace infomation to a file (which can be useful when you are trying to run down a problem and don't want the world to see your trace information during testing), it's as simple as this:

Add this to your web.config:

< trace enabled="true" traceMode="SortByTime" pageOutput="false" localOnly="false" />>

The key is the pageOutput="false" which tells the framework to redirect the trace info to the trace.axd file. To view the trace information, you just need to load the page in the browser, such as:

http://localhost:4774/trace.axd

This will allow you to see the trace history of any browsed files since the trace was started, as well as clearing the trace history. Just remember to remove this before you deploy (or make sure you compile in release mode!).

Tip of the Day: Debugging -- Conditional Breaks

Mon, 07 Sep 2009 22:46:14 GMT

Most people set break points, and iterate through code until they find the condition they were looking for. Although (IMHO) poorly documented, it's possible to place a condition on your breakpoint to have it stop when your condition is met.

Let's look at this code:

   20        
    int maxIdx = 15;

   21        
    for(int idx=1;
idx < maxIdx; idx++)

   22        
    {

   23        
        Response.Write("Index:" +
idx.ToString());

   24        
    }

 

If I were to place a breakpoint on line 23, the debugger
would stop every time it hit the Response.Write. For a small loop that *might* be
ok, but let's say I notice something weird with the 13th item. Within the breakpoint
itself, I can place a condition when I actually want it to stop, in this case, the
13th iteration.

 

By right clicking on the debug "circle", the following context-sensitive
menu comes up: 

 

Select "Condition" and the following dialog appears:

In the textbox, place the condition that you want. In this case, when idx == 13, the condition is true, and therefore, the breakpoint will now be active and execution will stop.

When a condition for a breakpoint is set, you'll notice the image for the breakpoint changes as well:

Tip of the Day: Debugging -- Break on Error

Mon, 07 Sep 2009 22:28:20 GMT

This has been around for quite some time, but I am always suprised when I go to a new client site at the number of developers who don't know how to make the debugger stop when it encounters an error. This is a repeat tip of a long time ago, as it's just that useful. It's a very useful debug trick because some projects are so large, you don't know where to start looking for an issue. Additionally, an error may actually be occurring somewhere unexpected because it's getting caught in error handling.

By setting it to break on "Thrown", the debugger will stop right where an error originates. To turn this functionality on, you can select the "Debug" menu item, and select "Exceptions". For you hot key fans out there, you can invoke the dialog with Ctrl+Alt+E. When you do, you'll see the following dialog. Mark the "Thrown" box for the "Common Language runtime Exceptions" as shown below.

When done debugging, save yourself some grief and uncheck the "Thrown" box, otherwise you'll be stopping a LOT when you don't mean to.

New feature in .Net 2.0 Exception object

Tue, 13 Jun 2006 15:42:38 GMT

There's a pretty useful feature (IMHO) in the .Net 2.0 Exception object which I hadn't noticed before. The Exception object contains a new Data interface, which is essentially an IDictionary for applying additional values to the exception object. I am currently using it with my integration of the new VS2005 Enterprise Library into our framework.

I want to log exceptions to a database, but I have found it useful in the past to have an Error #. In the old days (VB 6, for example) I could usually look at the error number of an application and tell exactly what the problem was. When .Net came into being, we lost the error number, and there was no easy way to get around it. You could roll your own exception classes of course and add these properties, but this is only a limited solution because other exception handlers wouldn't be capable of handling the additional features by default.

Now this feature is going to allow me to take advantage of error numbers by classifying each exception type, and appending an error number to the exception object. I can use this information in my database to classify and group errors by type to identify weak areas in an application as well. Not Earth shattering, but still a useful feature full of all kinds of possibilities.

A change of directions...

Fri, 28 Apr 2006 15:38:06 GMT

So it has been hit or miss posting here, but I am trying to correct it by bringing on some additional help. I set up a new blog, developernation.net, and begun getting some content on there. Likely I'll crosspost on here too (my content anyways) but likely most new entries are going to be there first. I figured if I could get someone else on there helping doing some content, it will have more regular posts. This blog will continue, just a lag a few days on the content of theother site, and contain more personal observations.

So swing on by and pop in. I've started off with a bang, and I am in the process of posting a web service design I created and tested which handles paging and sorting of data on the server, which my initial tests have shown to be highly efficient. I am walking through the entire design, and by the end of the weekend I hope to have the series done and the code posted. If not, you can wait a few days and I will post it all here as well.

Thanks!

Web Service Issues Part II: The Underlying Connection was closed

Thu, 16 Mar 2006 05:19:42 GMT

Previously, I discussed how I worked around a firewall issue where the HTTPS port was re-mapped, and the return URL was different than the request URL as a result of that remapping. So I trudged on, and hit a real stumper. Here’s the new issue:

The underlying connection was closed: Could not establish secure channel for SSL/TLS. Inner Exception: The function completed successfully, but must be called again to complete the context

I ran across Jan Tielen’s blog post (http://weblogs.asp.net/jan/archive/2004/05/08/128394.aspx) where he provided a code snippet to override the GetWebRequest method in the Reference.cs file. I implemented it, and it worked great --- on my development machine! However, when rolled out to the same test environment, the problem remained. However, I modified it futher, and got it to work..

/// <summary>

/// Set web request properties here

/// </summary>

/// <param name="uri">uri </param>

/// <returns></returns>

protected override System.Net.WebRequest GetWebRequest(System.Uri uri)

{

System.Net.HttpWebRequest webRequest = (System.Net.HttpWebRequest)WebRequest.Create(uri);

webRequest.AllowWriteStreamBuffering = true;

webRequest.KeepAlive = false;

return webRequest;

}

Sort of. When I tried to use DIME with the above code, it gave me an error “Client found response content type of '', but expected 'text/xml'”. That was not going to work. I found some more code, and it seemed to work great once again, until I tried to make a DIME call. Here was that attempt.

protected override System.Net.WebRequest GetWebRequest(System.Uri uri)

{

WebRequest request = base.GetWebRequest(uri); ;

if (requestPropertyInfo==null)

requestPropertyInfo = request.GetType().GetProperty("Request");

HttpWebRequest webRequest = (HttpWebRequest)requestPropertyInfo.GetValue(request,null);

webRequest.KeepAlive = false;

webRequest.ProtocolVersion = System.Net.HttpVersion.Version10;

return request;

}

Once again, it worked fine during my WSE calls, but failed when trying to use DIME attachments with the following error: found response content 'application/dime', but expected 'text/xml'

To save any readers some time, I will go through everything I tried to resolve the problem, and finally, how I ended up resolving it. Here’s the items which didn’t work:

-- tried setting the SoapActor

-- tried turning off the Document protocol

-- tried setting the request and return URI

-- tried overding the GetWebRequest function a few different ways

-- tried using wsdl instead of asmx in setting up the Web Reference

-- tried setting the URI target/destination seperately

-- moved web service to the same machine as the calling web site (but still had to make an external call)

-- turned on tracing input and output and analyzed the logs created by WSE 2.0

So what finally worked? I ended up abandoning DIME, and encoded the file as a string, and passed it as an element of my XML. Here’s the code to encode the file as a string.

/// <summary>

/// Encodes the file in a Base64 string format.

/// </summary>

/// <param name="file">Name of the file.</param>

/// <returns></returns>

private string EncodeFile(HtmlInputFile file)

{

try

{

if (file.PostedFile.ContentLength > 0)

{

byte[] fsBytes = new byte[file.PostedFile.ContentLength];

System.IO.Stream fileStream = file.PostedFile.InputStream;

fileStream.Read(fsBytes, 0, file.PostedFile.ContentLength);

return Convert.ToBase64String(fsBytes);

}

else

return String.Empty;

}

catch (Exception ex)

{

//Handle the Error

return String.Empty;

}

What a trip it was to get there, but the resulting service has performed well, and I don’t have the issues I had with DIME. Don’t get me wrong, DIME worked great. But deployment of the web service in a secure environment proved to be quite a challenge. If you need more detail in resolving your issue, feel free to leave a comment or shoot me an email, and I will be glad to save you some of the pain I had to go through!

VS2005 Provider Model and the config file

Tue, 14 Mar 2006 17:52:31 GMT

Just a little tip, as I didn't read the error message generated as closely as I should have. I was working this weekend on the Microsoft Code Template for Building a Provider Based Feature and was migrating some existing libraries I had for VS2003 to take advantage of the features in VS2005.

First, let me say I love things in VS2005 like Generics, and the implementation of the Provider Model. I was migrating my data access libraries and error handling libraries, and was setting up some tests in nUnit as part of ongoing testing. Although I haven't changed my data and error handling models in a long time, I figured it was a great design idea to be able to change them dynamically using the Provider Model.

To make a long story short, I was running my tests for the data library, and when I invoked my Data Access classes, I was getting a "TypeInitializationException" error. I checked and double-checked my configuration file, and it appeared to all be correct. I looked at the InnerException, and it didn't seem to be much more help. However, I went further to look at the InnerException of the InnerException, and there's where I found the solution. The Rosetta Stone?

Only one <configSections> element allowed per config file and if present must be the first child of the root <configuration> element.

A quick check indicated that I hadn't made the configSection the first element. Doh!

So there are a few lessons to learn here. 1) Make sure your configSections is first (normally not a problem, just a cut and paste issue here) and 2) Make sure you dig REAL deep into the InnerExceptions for the details and 3) the new Visualizers in vs2005 were too cool and very helpful.

Hats off to the VS2005 IDE team! It's spawned a few visualizers I can think of, so if time permits in the future, I will be publishing those right here!