Blog Archives

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

Today was the first time I have worked on our Azure application in quite a while, so I was unpleasantly surprised when I got the latest version of the code, clicked run and was greeted with :

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

CommunicationObjectFaultedException

After a lot of poking around and reinstalling the SDK I finally found the solution.  Apparently when running an application under Azure SDK version 1.3 the development environment needs to modify the web config in some way.  However, since I am using TFS for source control, the file was marked readonly and could not be edited.

The work around seemed pretty simple, just remove the readonly flag and off we go.  The next problem is that every time you get latest from source control the file gets marked readonly again and now it won’t run. 😦  To get around this just add a post-build command to your project to automatically remove the readonly flag when you run your project.   To do this right-click on your project in the Solution Explorer and select properties.  Go to the Build Events tab and enter the command : attrib -r “$(ProjectDir)Web.Config” .

attrib -r "$(ProjectDir)Web.Config"

Converting to Framework 4.0

We all would prefer to work with the latest technology. Unfortunately we often have applications that we built just yesterday using the last version of a framework, which is now so ancient history.  Luckily when it comes to .Net Applications Microsoft has done a great job of putting together conversion wizards to bring that old app up to the latest framework.

In this article I’ll walk through the relatively painless conversion process and then highlight a couple of things I have found to be pain points in the last couple of weeks as I have migrated applications to .Net 4.0 / Visual Studio 2010 from .Net 3.5 / Visual Studio 2008.

Converting an Application

To start you’ll need to have the latest version of Visual Studio 2010.  For the purpose of this article I’ll use Visual Web Developer 2010 Express to convert an application previous built in Visual Studio 2008.

vsopen

I usually make a copy of the project ahead of time in a separate folder before beginning,  That way if something goes wrong then nothing is lost.  (Although I have never had a conversion fail in an unexpected way.)

Go to File|Open Project … and browse to your solution file (*.sln) and open it.  The disk will churn a bit and you’ll be presented with the conversion wizard.

ConversionWizard

Click next and Visual Studio will ask you if you want to back things up first.  Since I am already working on a copy I choose no here.  I just don’t really like were Visual Studio puts the back up by default, which ends up being along side your project.

BackUp

Clicking next will bring you to the confirmation screen.

Finish

Now the disk will churn for a bit again and then you will get a dialog asking if you want to upgrade to framework 4.0 as well.

Convert

If you click no here your project will be converted to the 2010 Project format, but it will be left targeting the 3.5 framework (You can switch that later if you wish in the project properties).  If you click yes, the project file will be updated and the framework will be set to 4.0.  Pretty straight forward…

results

Once you choose an option things will churn a bit again and eventually you’ll be presented with a Conversion Report.

I did get a failure here, but it was expected.  The particular solution I converted had a number of projects in it including a couple of libraries, a web application, and a WinForms application.   Since I am opening this with Visual Web Developer the WinForms application did not load.  No problem, that was expected.

A Couple of Things to Note

After doing a few conversions I have run into a couple things you should know.

  1. In Framework 3.5 the Menu control renders by default as tables.  In 4.0 it renders by default as an unordered list.  The control has a property (RenderMode) that can be set to Default, Tables, or List.  So it’s your choice, you can set the value to Tables and move happily along, or convert things to work correctly as a List. If you choose to set it to List, I would, recommend setting the property to List explicitly.  I’ve seen things behave differently in different environments (IIS Versions) when set to default.
  2. There is a “Known Issue” in 4.0 where if you call __doPostback(‘foo’, ‘bar’) inside an AJAX Update Panel and the referenced control is not outside the Update Panel then nothing seems to happen at all.  The work around is to put a control with the specified name outside the Panel, however I have not tried this yet, In this particular case I opted to back off the 4.0 conversion for now because that change would have to be made in a number of complicated places in a critical application and it will require a large amount of testing to confirm the fix.  I converted this application to Visual Studio 2010, but left it at Framework 3.5.
  3. In the case when you have an ASP.Net web form that is allowing for example, HTML input, you may see an error something like: “A potentially dangerous Request.Form value was detected from the client…”.  We used to set RequestValidation=”false” on each page to get around this, but this does not in and of itself work in 4.0.  In 4.0 you will need to add an attribute(requestValidationMode=”2.0″) to the httpRuntime element in your web.config file to allow you to override the RequestValidation on the page level.  It looks something like this.

<httpRuntime requestValidationMode=”2.0″ />

You do still have to also set RequestValidation=”false” on the page as well.

More Information

There is a decent whitepaper on breaking changes in 4.0 on the ASP.Net web site at http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes