# Saturday, November 07, 2009
More promising features of VS2010
Saturday, November 07, 2009 3:45:19 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, September 25, 2009
Placing page trace information in a file instead of on the page
Friday, September 25, 2009 6:11:05 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, September 07, 2009
Debugging trick for placing a condition on a breakpoint to assist in speeding up debugging.
Monday, September 07, 2009 11:46:14 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
How to make the Visual Studio debugger break where the error actually occurs.
Monday, September 07, 2009 11:28:20 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, June 13, 2006
New Data property of the Exception class is quite useful!
Tuesday, June 13, 2006 4:42:38 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 
# Friday, April 28, 2006
A new blog...
Friday, April 28, 2006 4:38:06 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, March 16, 2006

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!

Thursday, March 16, 2006 5:19:42 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, March 14, 2006

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!

Tuesday, March 14, 2006 5:52:31 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  |