Solving a "The section is marked as being protected..." Error When Decrypting a .config With aspnet_regiis.exe tool

If you use the aspnet_regiis tool to encrypt sections of a .config file then you are ahead of the game is securing sensitive information with the apps configuration. If you have not used it before, I suggest trying it out sometime. However recently I came across an error while decrypting the 'appSettings' section that was as follows:

"The section is marked as being protected, but it does not have the correct format. It should contain only the <EncryptedData> child node."

It turns out that a new key that was auto generated in this particular project dealing with WCF was injected between the <EncryptedData> nodes (as shown below).

      </CipherData>
    <add key="ClientSettingsProvider.ServiceUri" value="" />
  </EncryptedData>

Once I removed the new key and attempted the decryption, everything worked properly! So if you come across this error, see if any new keys have been added (or any other elements for that matter) between the <EncryptedData> nodes because it will cause this error.

Get a free MSDN Magazine Digital Subscription

Here is some good news: you can subscribe to get a digital edition of the MSDN Magazine for FREE! The MSDN Magazine (normally a $35 annual rate for paper copy) covers software development topics related to Microsoft technologies. Just click the link below and login with your Windows Live ID to sign up. It used to come with Dr. Dobbs Journal as well, but I read it ceased subscription in early 2010.

Free MSDN Digital Subscription

Help! My .NET Setup Package Is Throwing a System.BadImageFormatException Error 1001

Recently I had a WCF service install package that was upgraded from VS.NET 2008 to VS.NET 2010 fail with the following error message upon installing it locally on my machine:

"Product: MyWCFService -- Error 1001. Error 1001. Exception occurred while initializing the installation: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files\MyApps\WCFServices\MyWCFService.WinServiceHost.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.."

You might also see the following warning issues by the compiler:

"The target version of the .NET Framework in the project does not match the .NET Framework launch condition version '3.5.30729 '. Update the version of the .NET Framework launch condition to match the target version of the.NET Framework in the Advanced Compile Options Dialog Box (VB) or the Application Page (C#, F#)."

Well this was interesting to me because this was being displayed on a machine that has everything: .NET Framework 4.0, tools, you name it. There should be nothing missing. That's the 1st place to start obviously - make sure the .NET Framework is installed on the target machine.

However this was not the case in my scenario. It turns out even though all of my project comprising the setup package targeted the .NET Framework 4.0, and even the Setup package prerequisites indicated the .NET Framework 4.0, there was still 1 piece of the puzzle missing.

The problem: under the "Detected Dependencies" list for the setup project the 1st item listed was "Microsoft .NET Framework". Refreshing the dependencies does nothing for this value; it must be reconfigured manually. Double click the "Microsoft .NET Framework" item to bring up the "Launch Conditions" window and properties. In the 'Properties' window, change the 'Version' attribute to .NET Framework 4.0 (or whichever framework for your scenario). The Launch Conditions window is displayed below. After making the change, the installer package worked perfectly and installed without issues.

How to Serialize a SyndicationFeed Object To Be Returned From WCF

Recently I have been working with the SyndicationFeed class in the System.ServiceModel.Syndication namespace. It allows us as developers to work nicely with Atom 1.0 and RSS 2.0 content. A problem arose when I needed to return this object from RSS to a consuming Silverlight client. The problem was that the raw SyndicationFeed class is not serializable, so I needed a solution to serialize the Feed and return it.

This was one time I was happy to find that no custom serialization methods, or mimicking all property values in my own DataContract to return was going to have to be the solution. Instead there are 2 nice classes in the same namespace that do exactly this for us: the Atom10FeedFormatter & Rss20FeedFormatter classes.

In my case I was working with Atom 1.0 content so I was able to use that Serialization class. The solution was simple. Alter my WCF service to return a type of 'Atom10FeedFormatter' defined both on the OperationContract and implementing service method. Then the client can define the return type to receive, and place it right back into a SyndicationFeed object if desired. There are also Atom10FeedFormatter(Of TSyndicationFeed) & Rss20FeedFormatter(Of TSyndicationFeed) classes to serialize classes that derive from those types, and there are all the same classes for the 'SyndicationItem' object as well. Needless to say there is some flexibility in serializing this data to be returned.

So let’s take a look at the code; 1st the code to extract a SyndicationFeed (i.e. from an RSS link off the web).

'Make a call to extract RSS information from the web
Dim proxy As New WebClient()
'Load stream into a reader
xmlRdr = XmlReader.Create(proxy.OpenRead(New Uri("http://rss.cnn.com/rss/cnn_topstories.rss")))

'Load syndicated feed (Atom)
Dim feed As SyndicationFeed = SyndicationFeed.Load(xmlRdr)

Next the code to Return from the method the Atom10FeedFormatter. I do this inline in the Return statement as it is easiest:

Return New Atom10FeedFormatter(feed)

Lastly, the client code to receive the Atom10FeedFormatter and place it back into a SyndicationFeed object. You may wish to do this before binding to controls.

Dim wcfSrv As New MyWCFService.MyWCFServiceClient
'Create the Formatter which will be returned from the RSS call below
Dim MyRssSyndicationData As Atom10FeedFormatter
MyRssSyndicationData = wcfSrv.RssFeedData()

'Load the returned formatter back into a SyndicationFeed object if desired
Dim RssDataFeed As SyndicationFeed = MyRssSyndicationData.Feed

So that's it! If you want to learn more about these classes that make serializing SyndicationItem or SyndicationFeed classes so easy, take a look to the following link:

System.ServiceModel.Syndication Namespace

Microsoft Offers Free VB6 to VB.NET or C# Conversion Tool

Microsoft has released 'ArtinSoft’s Visual Basic Upgrade Companion (VBUC)' as a free downloadable tool to convert old VB6 code into .NET code (either VB.NET or C#). It appears to be good for converting up to 10,000 lines of code under the free license. See the link below for more details:

ArtinSoft’s Visual Basic Upgrade Companion (VBUC)

Fixing the "File type isn't supported" Error When Working With Expression Encoder SDK

Recently I had trouble on a Windows 7 Ultimate Machine with Expression Encoder 4 installed with a "File type isn't supported" error being returned when programming against the SDK. Upon creating an instance of the MediaItem object, the exception was thrown. It turns out even with Win7 ultimate, EE4, and Windows Media Player 11 installed I was still missing some codecs. I downloaded a robust codec pack from the link below and it solved the issues. Microsoft also offers a codec package for older versions of Windows Media Player, but to make sure I had no more issues I installed the larger free package offered from CNet. Once the additional codecs were installed, the code continued to work perfectly. Remember as well, if this code is in a service or .dll, make sure those codecs are in place on machine or server where deployed as well, to prevent the "Well it works on my machine, but not the server..." kind of issue.

Media Player Codec Pack

Codec Installation Package for Windows Media Player 7.1 and later

How to Fix When a WCF Service Does Not Debug via the "WCF Test Client" Tool

If you have created a WCF service, then you have probably seen that upon debugging the service via VS.NET, the service is started automatically using the WcfTestClient.exe tool. This allows the service to actively run through the development server, so test harness applications can consume the service and have real time debugging capabilities. The image below shows the window that should display upon successfully starting (debugging) a WCF Service.

Recently I had a WCF service that upon debugging was opening a web page with the .svc details being shown. This was not what I wanted, and my other VS.NET WCF service started just fine using the WcfClientTest tool. I checked all of the project properties and couldn’t find any setting that triggered this tool to be started.

Upon doing some digging, these configuration attributes are in the .vbproj or .vbproj.user files (.csproj or .csproj.user for C# projects). In the .vbproj file the <EnableWcfTestClientForSVCDefaultValue> tag needs to be present and set to 'true'. This can also be done in the vbproj.user file, but it is the <EnableWcfTestClientForSVC> configuration and it would also need to be set to 'true'. Only the configuration in the main .vbproj file is needed for the WCF service to start using the WcfClientTest.exe tool. Sure enough an older service of mine was completely missing this configuration. The proper configuration element is displayed below.

<ProjectExtensions>
  <VisualStudio>
    <FlavorProperties GUID="{123c5851-25df-10da-9384-00011b846f00}">
      <WebProjectProperties>
 <EnableWcfTestClientForSVCDefaultValue>True</EnableWcfTestClientForSVCDefaultValue>
      </WebProjectProperties>
    </FlavorProperties>
  </VisualStudio>
</ProjectExtensions>

You can open either the .vbproj or vbproj.user files by right-clicking in Windows Explorer and opening with notepad. Once the configuration is added and set to 'true' the service will launch using the WcfClientTest.exe tool as expected.

Setting Up the ClientBin Folder to Debug a Silverlight Control in a Test ASP.NET Application

If you create a new Silverlight control using either VS.NET 2010 or Expression Blend 4, you are already off on the right foot for setting up a test ASP.NET application for running and debugging a Silverlight control. The newer versions of these applications configure well the test project, creating the 'ClientBin' folder, and associated test .aspx page including preconfigured <object> tags referencing the control.

But what if you have an old or mis-configured project that manually references a .xap file, or had to be constantly updated in Explorer in the referenced path? It is especially important to have the configuration correct in a test app or debugging the .xap from the source Silverlight project is not possible. The following steps describe how to easily reconfigure your ASP.NET test harness to properly reference the .xap generated from the Silverlight control created within the same solution.

1. Right click the ASP.NET test project and select 'New Folder'. Name it 'ClientBin' (without the quotes). Only do this step if the folder does not already exist.

2. Right click the ASP.NET test project (this project should be in the same solution as the Silverlight Control being referenced) and select 'Properties' (or 'Property Pages' for website projects).

3. While still in the Properties, open the 'Web' (for web project types) or 'Start Options' (for website types) and make sure to scroll down and have the 'Silverlight' checkbox checked under 'Debuggers'.

4. Select the 'Silverlight Applications' tab or selection on the left hand pane.

5. Click the 'Add' button to bring up the 'Add Silverlight Application' dialog box.

6. Make sure the radio button selection for 'Use an existing Silverlight project in the solution' is selected, and select the Silverlight control to reference.

7. In the 'Destination folder:' field, make sure 'ClientBin' is in the textbox. This will most likely be pre-populated.

8. Configure the remaining options to your liking. I suggest leaving 'Add a test page that references the control' checked as this will save you from having to do this from scratch.

At this point try starting debugging the Silverlight code by placing a breakpoint in the source. Obviously make sure the ASP.NET test app is set as the default project, and set the newly created page to be the startup page. If you configured it correctly, your code will properly place any new builds of the .xap into the ClientBin folder of the test app, and should allow for proper debugging.

Fixing the "attempting to access a service in a cross-domain way..." error when consuming a WCF service running via a VS.NET 'localhost' binding

There must be 1000 good blog posts about setting up the clientaccesspolicy.xml and crossdomain.xml files for a WCF service being accessed by a Silverlight application or control. This consists of dropping these files in the root of the site on the server where the site is hosted. But where do these guys go if you are actively running your WCF service locally (through VS.NET) and still want to consume the service?

I recently had my WCF service running through VS.NET so I could consume and debug it through an ASP.NET test harness. This is a really powerful way to iron out any WCF service issues. Upon launching the .aspx page that contained the .xap Silverlight control that had consumed the localhost version of the WCF service running (not a locally installed WCF service to reiterate; just actively running through VS.NET) I began to get the following exception:

"An error occurred while trying to make a request to URI 'http://localhost:6000/MyWCFService.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent."

What - I thought I fixed this a long time ago?? I realized I had never configured the clientaccesspolicy and crossdomain .xml files just for a service running locally. I started plopping those (2) files everywhere: wwwroot, project, etc. I finally found where they should be placed in order for an ASP.NET app containing a Silverlight control that has consumed a locally running WCF service is supposed to go: in the root of the project folder alongside the .svc and .vbproj files. Once I placed the (2) files into that directory containing the raw VS.NET files, the SL control began working properly.

Makes 100% sense too. If running through VS.NET Cassini local server, those files should be located with the actual service itself.

Again, this is only 1 of many, many ways to solve the original issue at hand. This is only a solution for Silverlight controls that consume a locally running (not installed) WCF service. Hopefully this saves someone else a few minutes.

Updating Microsoft Charting Controls for .NET from VS.NET 2008 to VS.NET 2010

If you recently did an upgrade of a project from VS.NET 2008 to 2010 that contained the Microsoft Charting controls for .NET, then you probably encountered some errors upon 1st run if you are now targeting the .NET Framework 4.0. The solution is to upgrade the charting references to the new .dll version throughout the application.

One possible exception you may have encountered immediately is the following:
"'Legend' is ambiguous in the namespace 'System.Web.UI.DataVisualization.Charting'."

This all points to the need to update the references to the 4.0.0.0 version of the System.Web.DataVisualization.dll used by the MS Chart controls. The following steps need to be completed to get your project current and working with the 4.0 version of the Chart controls.

1. Remove the reference to the System.Web.DataVisualization .dll in the project. If just converted it will still be referencing the 3.5.0.0 version of the .dll.

2. Add a reference to the new 4.0.0.0 version of the .dll from the '.NET' tab when adding a reference to your project. You can view the 'Version' column to make sure you have the correct reference.

3. In the web.config, update the version number in the 'Controls' tag from 3.5.0.0 to 4.0.0.0. Nothing else needs to be modified; the PublicKeyToken, etc. are all the same. Just change the version number. The corrected configuration is displayed below:

<pages>
  <controls>
    <add tagPrefix="asp" namespace="System.Web.UI.DataVisualization.Charting" assembly="System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </controls>
</pages>

4. In the web.config, update the version number in the 'assembly' tag for the System.Web.DataVisualization reference from 3.5.0.0 to 4.0.0.0 if not already done. This may have been updated when adding the reference in Step #2, but if not go ahead and modify it now. The corrected configuration is displayed below:

<add assembly="System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

5. In the web.config, update the 'httpHandlers' section for "ChartImg.axd" version once again from 3.5.0.0 to 4.0.0.0. The corrected configuration is displayed below:

<httpHandlers>
  <add path="ChartImg.axd" verb="GET,HEAD" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>
</httpHandlers>

6. In the markup of any page using the Chart controls, remove the page registration for the assembly; just delete it. The next step will add back in the proper registration.

7. From the 'ToolBox' under the 'Data' tab, drag a 'Chart' control onto your existing page. This simple method will create the proper registration at the top of the page. Make sure to modify the 'TagPrefix' to the proper value if you had changed it previously from the default 'asp' used. After the registration is added back to the page, you can delete the chart control dragged on the page; it was just used to create the proper registration (this happens whenever a new control is dragged onto a page). Repeat this step for any pages that have a chart control on them. The proper page registration is shown below:

<%@ Register Assembly="System.Web.DataVisualization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
    Namespace="System.Web.UI.DataVisualization.Charting" TagPrefix="asp" %>

8. Rebuild your solution and run it. Your MS Chart controls should now be displayed properly!

As an additional reference, the MS Chart samples for .NET have been updated for the .NET Framework 4.0. If you have any additional problems, download the samples project and view the code or markup. You can find the samples at the following link:

Samples Environment for .NET Framework 4 Chart Controls Released!