Dot Net Technologies -- MS Tech talk and more - Web Services

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

Sat, 31 Oct 2009 04:22:38 GMT

As I mentioned before, I historically have avoided beta software. However, this time I am breaking that rule and really digging into VS2010 early. Below are a few of the things which have me very excited to see this release (and with Web Spark, I get it for free! Join now!) This is part one of a multi-part entry of the things I find really appealing about the upcoming version of Visual Studio 2010.

IntelliTrace – allows you to playback and trace a session to assist with debugging. The major features are:

Application Event Recording
Playback Debugging (a.k.a Time Travel Debugging)
Record and Playback of Manual Test Failures
Debugging Build Acceptance Tests
Diagnosing Unit Test Defects
Debugging Load Test Failures

Link: http://blogs.msdn.com/habibh/archive/2009/06/02/an-in-depth-look-at-the-historical-debugger-in-visual-studio-2010-part-i.aspx

Auto-Start applications – Helps mitigate large startup processes which may run during the web application “Application_Start” event. Provides a controlled approach for starting up the application.

Link: http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx

Better ViewState management – By default, ViewState is enabled for web controls in past versions of ASP.Net. In VS2010, ViewState can be disabled by default and onlt enabled for those that actually need it, and it now supports “inheritance” through the ViewStateMode property. This allows you to set it to “Inherit” the value from the parent control.

Link: http://www.asp.net/learn/whitepapers/aspnet4/

Outut Caching everywhere -- Now you can take advantage of caching in applications other than web based, as the cache API is exposed without using the System.Web.Cache in a WinForm application. There are also more providers, and the ability to create your own through extensibility.

Link: http://www.asp.net/learn/whitepapers/aspnet4/

Reduced web.config size – Most of the configuration settings have been moved to the machine.config file, which greatly simplifies the configuration settings in the web.config file.

Link: http://www.asp.net/learn/whitepapers/aspnet4/

Get the VS2010 Beta 2 here: http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

A not-so-shameless plug

Fri, 07 Aug 2009 05:02:11 GMT

I finally got around to updating my resume, and I pasted it temporarily on my home page at Rubicon Computing Solutions. That's my company, and it's been a great run of 13 years. I say temporarily simply because it will better positioned later, but I realized I really should have it on there so it gets picked up by some search engines, recruiters and in general people looking for .Net development in the Phoenix area.

I am in some talks with some other very senior developers I have had the pleasure of working with over the past couple of years about banding our talent together. I've tried that before, but these developers have been on their own for a long time, so we have a very similar background and strong work ethic to build upon. I have always struggled in the past with partnering up with other developers, as I have very high expectations of any project I work on. In fact, this is why I have had trouble hiring help, as my standards of quality aren't met by most developers without substantial coaching. These developers already have that skill, along with maturity and experience, which makes this a very exciting opportunity. Interesting how this economy drags some people down, yet others, like myself see it as an opportunity.

One of the limiting factors I have always had was that I was limited on the size of projects I could take alone. This changes that dynamic dramatically.

So if you're looking for some quality application development (web or windows), I specialize in quality service and coding in a Microsoft environment. I can work alone, with a team, or build and lead teams. You can find more details about those skills here. Thanks!

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!

Web Service Adventures - The <To> header must match the value of an incoming message's HTTP Request Url if the soap receiver does not have an actor name.

Thu, 09 Mar 2006 16:12:20 GMT

At my current client, security is taken to a whole new level, which is a good thing. But as a result, sometimes there is more of a challenge to resolve issues you may not normally encounter. For example, I was tasked with writing a web service which would facilitate file transfers of documents and images from a web page (and Windows client), store them on a secured server, and serve them up to an authenticated user on the internet. To do so, we have to deal with proxy server issues and firewall issues.

After writing and testing the web service locally, I deployed it to our production server. Locally, it all worked fine. However, when I deployed the web portion of the application to our test server outside our intranet, the real fun began. The next several posts I will discuss the problems I encountered, and how I ultimately resolved the issue. Hopefully this will help any readers out there who have a similar issue, as well as become documentation for the process I used so I can later reference it.

The first issue I saw was the following error:

The <To> header must match the value of an incoming message's HTTP Request Url if the soap receiver does not have an actor name.

I'd love to give the person I found the solution at credit, but it's been such a long time I can't find the original document I used. I modified the solution to make it a little more "generic" so that the web service can be moved without requiring a recompile of the application.

First, you'll need to locate the Reference.cs file for the web service reference(for C# users. Reference.vb is the similar file for VB.Net, but all code here will be in C#). In this file, add the following reference:

using Microsoft.Web.Services2.Addressing;

Next, locate the consructor for the WSE portion of the Reference.cs. In this case, mine will be FileServiceWse(). Here's the code you'll need to replace the this.Url reference already in there.

public FileServiceWse() 

        {

            //these
two setting are the <TO> and Response URLs. For example, in our case the response
was

            //coming
back with the redirected port appended to the url.

            //The
Web service <TO> looked like https://mycompany.com/FileService/FileService.asmx

            //but
the response was https://mycompany.com:1234/FileService/FileService.asmx

            //The
endpointreference call to the Destination tells the application to expect the return
url to look differently than the

            //<TO>
reference

            string urlSetting
= System.Configuration.ConfigurationSettings.AppSettings["FileService"];

            string urlReturnSetting
= System.Configuration.ConfigurationSettings.AppSettings["FileService.ReturnURL"];

            if ((urlSetting
!= null) && (urlReturnSetting != null)) 

            {

                Uri sourceUri
= new Uri(urlSetting);

                Uri returnUri
= new Uri(urlReturnSetting);

 

                this.Destination
= new EndpointReference(sourceUri, returnUri);

            }

            else 

            {

                if ((urlSetting
!= null)) 

                {

                    this.Url
= string.Concat(urlSetting, "");

                }

                else 

                {

                    //this
is the default URL of the file service if all else fails.

                    this.Url
= "https://mycompany.com/FileService/FileService.asmx";

                }

            }

 

        }

What this code does is set the Destination property (if the FileService and FileService.ReturnURL settings are placed in the web.config file) to expect a different response than the requested web service URL. In our case, since our request was going through a firewall which remapped the ports, we had a port attached to the url for our web service which triggered this error.

The code also has failover. If I forget to make the settings, it will try the original URL reference. In my case the call won't work, but I believe in at least attempting to code some failover when human error can take place in moving files, etc.

But this only solved one of the many challenges I encountered in deploying this web service. Stay tuned for the next resolution to tricky WSE issues!