Fixing The SignatureMismatchException When Updating NuGet

Recently I was trying to update the NuGet Package Manager for VS.NET 2010 from version 1.6.x to 1.7.x and ran across the following exception in the log presented when there is an error with the update process:

VSIXInstaller.SignatureMismatchException: The installed version of 'NuGet Package Manager' is signed, but the update version has an invalid signature. Therefore, Extension Manager cannot install the update. at VSIXInstaller.Common.VerifyMatchingExtensionSignatures(IInstalledExtension installedExtension, IInstallableExtension updateExtension) at VSIXInstaller.InstallProgressPage.BeginInstallVSIX(SupportedVSSKU targetAppID)
Install Error : VSIXInstaller.SignatureMismatchException: The installed version of 'NuGet Package Manager' is signed, but the update version has an invalid signature. Therefore, Extension Manager cannot install the update at. VSIXInstaller.Common.VerifyMatchingExtensionSignatures(IInstalledExtension installedExtension, IInstallableExtension updateExtension) at VSIXInstaller.InstallProgressPage.BeginInstallVSIX(SupportedVSSKU targetAppID)

The fix is simple; it requires an uninstall and reinstall. I assume updates within a version would work, but since I am actually upgrading I imagine this is what requires the uninstall 1st.

Go back to the Extension Manager and select "Installed Extensions", and then select the NuGet pacakage and press "Uninstall". Close and reopen the Extension Manager to refresh the installed packages, and search the Online Gallery for NuGet. If ordering by "Highest Ranked" it typically is the 1st or close to 1st item in the list. Now select "Download" and the installation will complete successfully.

Adding The HTML Target Schema Selection to VS.NET 2010 for HTML5 Intellisense

If you are beginning to delve into HTML5 in VS.NET say in a MVC3 project using the Razor engine for example, you will want intellisense support for HTML5. This is not difficult to do, but the 'HTML Source Editing' toolbar may not be shown by default in your VS.NET instance. To add it preform the following steps:

1. Open VS.NET but do not open any specific project. This ensures the changes you make will be for all project's opened.

2. Go to 'View -> Toolbars' and select the 'HTML Source Editing' menu item.

3. To test, open a MVC3 or MVC4 project using the Razor engine and navigate to a .cshtml view. The dropdown will now be active and the default selection will be 'XHTML 1.0 Transitional'. Change it to 'HTML5'.

4. Now try typing in the first few letters of a HTML element or attribute, like the 'Canvas' tag.

You now have the HTML5 schema validation and intellisense support.

Applying and Using a SSL Certificate With A Self-Hosted WCF Service

(Please read my 1st post on this topic called Create A Self-Signed SSL Certificate Using IIS 7 if you need to know how to create a self signed SSL certificate)

If you create enough WCF services eventually you are probably going to need to self host your WCF Service as opposed to using IIS. The most common way of doing this is probably a Windows Service which is a great environment to host WCF services as they automatically begin and end with the server and OS being up or down and are always running in the background.

However when using a Windows Service you might find it is not as straight forward to use a SSL certificate with your exposed WCF service. This is true as there is no wizard style interface for applying SSL certificates to Windows Services like IIS provides, however after following the steps outlined here you will see that it is not so bad. Overall the process is easy to repeat for multiple services and ports once you are used to doing it.

The 1st step is to configure your WCF service to use a binding and configuration that supports HTTPS and SSL. For this example, we will use a simple WCF service that uses the 'basicHttpBinding' configuration. As with any WCF configuration, remember the references to the contract Interface and implementing class are case sensitive so if you run into any errors check your spelling. The main configuration changes to allow HTTPS on the service are to change the metadata publication binding to 'mexHttpsBinding' and by setting 'httpsGetEnabled' to 'true' on the service behavior. The SSL is handled by transport-level security using certificates. The entire service configuration is below:

 <system.serviceModel>

<!--WCF Services Defined-->
<services>
  <service name="WcfServiceTest.MyWCFService"
           behaviorConfiguration="MyWCFServiceBehavior">
    <endpoint address=""
              binding="basicHttpBinding"
              bindingConfiguration="BasicHttpSSLBinding"
              contract="WcfServiceTest.IMyWCFService" />
      <endpoint address="mex"
                binding="mexHttpsBinding"
                contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="https://DevMachine1234:8050/WCFServices/MyWCFService" />
        </baseAddresses>
      </host>
  </service>
</services>

<!--WCF Service Behavior Configurations-->
<behaviors>
  <serviceBehaviors>
    <behavior name="MyWCFServiceBehavior">
      <serviceMetadata httpsGetEnabled="true" httpGetEnabled="false" />
      <serviceDebug includeExceptionDetailInFaults="false" />
    </behavior>
  </serviceBehaviors>
</behaviors>

<!--WCF Service Binding Configurations-->
<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpSSLBinding">
      <security mode="Transport" />
    </binding>
  </basicHttpBinding>
</bindings>

</system.serviceModel>

Notice the 'baseAddress' value I used. The most important part here is that the host name of the service must match that of the SSL certificate I bind to the port selected. In my instance the machine name is 'DevMachine1234' and so is the name of my SSL certificate. You can actually create a SSL certificate named 'localhost' if you prefer and use that instead. If this is a true production service and you make the service address MyWcfService.com, then you will need to get a SSL cert with a matching name from a provider like Verisign or GoDaddy. Test this all and have a complete understanding before spending money on SSL certificates; no use wasting money on a misunderstood process.

Also notice I selected port '8050'. This is arbitrary, but remember there are certain port restrictions, and only 1 SSL certificate can be bound to any single port. We now need to apply the SSL certificate for our service (we are using a self-signed certificate for testing purposes) to the 8050 port before we can test our service.

The 1st thing we need is the Thumbprint value from the SSL certificate. We can use IIS to look at the installed SSL cert and grab the thumbprint value. Open up IIS, and select 'Server Certificates'. Double-click on the appropriate SSL certificate and go to the details tab. Scroll to the bottom and find the 'thumbprint' value of the certificate. Copy it out from the 1st character to the last into notepad and remove all spaces. Take caution to not copy the 1st space as it will translate into a '?' (question mark) when pasted into the command window to apply the SSL certificate in a later step. Save this for the next step.

Begin by clicking on the 'Start' button in windows and type in 'CMD' in the search box but do not press enter yet. Right-click the 'cmd' program and select 'Run as administrator' as shown below. This ensures we add the SSL certificate to the port with proper rights.

We need to use the 'netsh' tool (replacement in W2K8 and Windows 7 for the old httpcfg.exe tool) to apply the SSL certificate. We need the certificate thumbprint (gathered above) and an application ID value. The easiest way to get the 'appid' value is to use the GUID in the 'AssemblyInfo' file for the WCF project as pictured below. Copy it out as well and have ready for applying to the command window in the next step.

The command to add the SSL certificate to the port we configured in our WCF service is as follows:

netsh http add sslcert ipport=0.0.0.0:8050 certhash=3e49906c01a774c888231e5092077d3d855a6861 appid={2d6059b2-cccb-4a83-ae08-8ce209c2c5c1}

After applying the command and pressing enter you should see a message that the certificate was successfully added.

If you want, you can verify it has been added and view any SSL certificate that has been applied by entering the following command:

netsh http show sslcert

You will see the command window output in groups displaying any SSL certificates that have been applied as shown below. Notice you can see the SSL certificate 'hash' value which is the thumbprint value we used.

If you were doing this process in a production environment or on a remote server, make sure to apply the appropriate SSL certificate that has been imported and installed on the server 1st, to the port you need prior to starting the Windows Service (it actually will not work without it).

At this point we are ready to start our service on our local machine. In VS.NET I set my service (not the host in this instance) to be the startup project. I then begin debugging. You will notice the 'WCF Test Client' tool will pop-up and display all locally hosted services. This is probably were most folks will encounter some errors. Read the error description because they are typically meaningful and give direction on what to fix. Odds are it is caused by the SSL certificate not being applied to the same port configured, a mismatched name on the certificate to the service's domain name, or a mistake in configuration. Go over all steps again to make sure everything is correct. As you can see below our WCF service exposed via a HTTPS endpoint is up and running.

The last step to verify everything is working properly is to copy the address of the locally hosted service and consume it in another test application.

Add the copied address as a service reference to the project and make sure you do not receive any exceptions.

The successfully added service will be shown in Solution Explorer with the name you provided.

My recommendation is to get all of this working as I did in a local test environment 1st and understand all of the pieces. For those totally new to WCF it can be a lot to digest and fixing problems can take time and a deeper understanding of WCF so be patient.

For more information on the other commands available to the netsh.exe command line tool (like removing SSL certificates from a port), please see the following reference:

Netsh commands for HTTP

Debugging Code Techniques In VS.NET 2010

OK so you have a problem in code either during development, testing, or production and do not know exactly how it is occurring. What do you do? For those of you that are thinking your code does not have problems or there should never be problems in the 1st place, please click here. For the rest of us in the real world, you might be thinking about a new tool like 'Intellitrace' to track down exactly when the error occurred. But not everyone has that environment created and even with using it, you still need to figure out *why* it occurred. How do we do this... DEBUG the code!

So now a lot reading this might think, "Well yeah I know all about debugging, simple stuff." That may be all and true but it surprises me how many developers out there based on questions I see asked a lot from an array of environments only know (2) buttons on the keyboard when it comes to debugging: [F10] and [F11] (Step Over & Step Into with default key mapping). Oh yeah and [F5], Start!

To be good at debugging and playing detective to track down problems or anomalies that cause problems, Microsoft has provided us with a plethora of debugging options within VS.NET. Most of the techniques have been around for multiple versions of VS.NET and *some* of the techniques still not known by a faction of developers stretches all the way back to the old VB Visual Studio IDE.

So let's review the (3) most basic debugging techniques: Step Into [F11], Step Through [F10], and Step Out [Shift + F11]. Step Into [F10] will execute each line of code, going into any method, property, etc. call. This is the most granular way to trace each line of code. Step Through [F10] will *not* go into code that makes up a property, method, etc. and rather execute that code completely without executing line by line, returning control to the developer to debug the next immediate line of code after execution has completed. The last one I mentioned, 'Step Out' [F11] is one I find under used even though this is functionality that stretches back to VBA and VB6 (ever watch someone hold down the F10 key or press it like they are tapping on a snare drum to exit out of a method?). What this does is allow the developer debugging to exit out of the method immediately allowing control to be passed back to the next line of code after the calling code to the current method was made, but still completes execution of the current method, property, etc.. This works well for the following example - let's say you have a method you are debugging and it is 50 lines of code. You need to understand what is happening between lines 5-10 and the rest is not important for what you need to know. What you would do is press [F11] to step into the method to debug and gather the information needed, but once you were finished observing lines 5-10 you want to return execution back to the caller but yet finish execution of the current method. You can do this by 'Stepping Out' of the routine by pressing [Shift + F11]. A lot better than placing a break point the line after the caller and pressing [F5] or trying to press [F10] another 30x to finish the method.

This really so far is super basic stuff and hopefully a bore or quick review to any intermediate or seasoned developer. But you know as well as I that the hard to track down issues, 'anomalies' happen all too often and there are a lot of other ways to debug and track down issues. One way I discussed previously is by using conditional breakpoints which I talked about in the following post: How to: Set a conditional breakpoint in VS.NET Ever press [F5] over and over hovering over a single variable value until the last name is 'Smith' or the value is 'x'? Well setting conditions on breakpoints to only stop execution when that condition is = True is well worth reviewing.

There are also several 'helper' tools that go along with debugging to help make the debugging process more efficient. So let's begin with a few tools to help with debugging. The 1st is 'Debug Labels'. Labels on debug points are useful to define descriptions or add attributes to help with individual breakpoints to provide information about it. This will carry over and be quite useful when exporting breakpoints as I will show next. So to begin, bring up the breakpoints window. The easiest way to do this is to press [Ctrl] + [Alt] + [B] on the keyboard. The window below shows this:


The Windows shows all active breakpoints and provides several sorting options and customizable features for breakpoints directly in the window. I will not go through them all here, so take a look and explore yourself. One very important feature to take note of in this window, is that any action you select to preform on the breakpoints will only be carried out on the actively displayed breakpoints as a result of any searches you have made. So If you have 10 total breakpoints, and preform a search that reduces the list down to 3 breakpoints, only those 3 in the search results will be acted upon. To clear any search criteria, press the 'X' to the right of the 'In Column' selection list.


In the block of code above I have set (2) breakpoints and notice they both display down in the Breakpoint Window displayed previously. What I want to do is create a label and assign it to this breakpoint. There are (2) ways to do this: either right click the breakpoint in the code editor or in the Breakpoint Window to bring up its options Window and select 'Edit Labels...'


To add a label, type in a description or attribute, and press 'Add' as shown below. There is a 64 character limit, and you can not have commas. You can add as many label descriptions through the window at a given time, and assign as many labels as you want signified by the checkbox(s) selected to the left of the requested label(s). These labels will be available for assignment to other breakpoints as well:


Once a label is created it can be assigned to 1..n breakpoints. Maybe you have a set of breakpoints that are similar and all need the same label. Another possibility is you have some sort of numeric order description. In this case the sorting ability in the Breakpoint Window is nice. Just sort the column to get the label description in order. This can help with a set of imported breakpoints or for walking through your own defined breakpoints. From this window you can search through the breakpoint labels as well. Just change the 'In Column' value to 'Labels', and type in the search criteria. The list will filter down based on the search results.


The next feature available from the Breakpoints Windows is the ability to Import and Export the breakpoints. Have you ever had that app you get out of source control and think "Ok I need to place (x) # of key breakpoints here, here, and here to do some task." Well what you should be doing is exporting your breakpoints and saving that file in source control. This is also really useful to pass along to other developers that might be working on your project. How nice for them to have descriptive (labels) pre-defined breakpoints already defined for debugging. The task is trivial: just press the save disk icon from the Breakpoints Window and the debug breakpoints will be exported to an .xml file. The import is just as simple. Just press the Import icon and select the .xml file where the breakpoints are defined. Don't forget to add these files to Source Control.

The next debugging technique helps with monitoring specific values but not having to stop execution to do so. They are called 'Tracepoints'. Have you ever been in a situation where you need to monitor a value of a variable and began writing 'Debug.Writeline' statements? Errrrr, No. Just use a tracepoint and monitor the same Output Window. This way you don't have to clutter up your code with debugging lines that later you might clear out or have to wrap in conditional #Debug statements. To create a tracepoint right-click on the actual breakpoint in the code editor or from the Breakpoints Window and select 'When Hit...'.


This will bring up a dialogue that allows you to type in some expressions to output needed information.


For example look at the following basic loop below.

For i As Integer = 1 To 10

Next

I want to place a tracepoint on the variable to see it's output in the loop. The expression I will use is as follows:

The value of i = {i}

In my case I will leave the option checked to 'Continue execution', so I can view the output, but not have to stop execution. Notice after adding the expression your traditional breakpoint is now a tracepoint which is displayed as a diamond.


Before executing the code, make sure to have the 'Command Window' present. If it is not, you can access it by pressing [Ctrl] + [Alt] + [O]. Now execute the code that will run through the configured Trace Point. Notice execution will not halt, but the expression you provided will be output to the Command Window. Notice for the simple loop, it output all of the values.


Pretty nice and all done through a tracepoint. No need for custom logging, Writeline statements, etc. This is an especially good technique for watching values during their lifetime throughout an application and helps solve the old "I swear I clear that value out...", or "Why does that variable loose value here but have value over there...', and many, many more examples.

The last (but by far not the last available technique) topic I am going to cover are 'Pinned Data Tips' while debugging. Ever hover over a value and have to remember it for later in execution, or jot down some notes about a particular debugged line of code? Well this feature is for you then. Begin by placing a traditional breakpoint on a line, and being execution of code until the breakpoint is hit. When you hover over the variable you will get it's current value. Ever notice there is a push pin on the end of the value? Yeah, go ahead and press it as displayed below.


To move the data tip around, just click and hold the pin to drag it off to the side if needed where there is more white space. You can also add comments to that data tip. Just press the down arrows, to get a text box for typing brief comments.

Notice as execution continues, or when you being a new debugging session the pinned data tip is still present! How cool, no more stickys on the screen or desk with random notes, values, etc. Notice how you will see it displayed as a blue horizontal push-pin in the pane where breakpoints are assigned in the editor. If it is on the same line as a breakpoint it will be mostly hidden.

As mentioned, once you being debugging again (even after stopping execution), you defined push-pins will reappear but there is one more useful added feature. Notice how the push-pin will display the last debugging session's value. This can be really useful to see how the code reacts to different input possibly, and doesn't require you to keep track of what the value was from the last time code ran through this breakpoint. The last value is displayed below:

Note: to clear any data tips, right-click the push-pin in the code editor and select 'Clear'.

These debugging techniques are just a small sampling of all of the available features. Feel free to add comments for any other features you find useful as well. The main point to drive home is that to be successful in software development will at one time or another require 'playing detective' and tracking down unknown issues, anomalies, or maybe just learning how code behaves line by line. To do these tasks well you have to be efficient at debugging. So if you are one of the few that admits they only knew about (2) or (3) Function keys used for debugging, try some of these and many other documented debugging techniques to help you expand your problem solving abilities in VS.NET.

Spell Checker Extension For VS.NET 2010

OK there is a really useful extension available for free to VS.NET 2010 named "Spell Checker". It shows misspelled words within commented sections with the traditional red squiggly line under the word as seen in Office products. Obviously correctly spelled words are not critical to an applications performance, but well formed internal documentation that reads well such as commenting is important.

You can download it for free by going to Tools -> Extension Manager and then select 'Online Gallery' from the left-hand side. In the search box type in the top-right hand corner, type in "spell checker" and search. The 1st extension created by Roman Golovin and Michael Lehenl (thank you) named "Spell Checker" is the one to download and install (shown below).



As you can see below, just hover the mouse over the misspelled word for the little box to display, which upon clicking will bring up the properly spelled words. There is also the ability to "Add to dictionary" which is nice, because often many words we use are technical and not in the dictionary.


It can also be downloaded directly from the link below:
Spell Checker Extension for VS.NET

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!

Using Auto-Properties and Traditional Properties with VB.NET in VS.NET 2010

Once you being using VS.NET 2010 as a VB.NET user, you will soon see the neat feature of Auto-Properties which C# users have enjoyed since VS.NET 2008. I will not go too much into them as the feature has been covered exhaustively across blogs and sites. In a nutshell the Auto-Property feature provides a short hand way of defining properties without having to fully write out the Get and Set code, along with the backing variable.

But what if you do need a more advanced property, where the data is manipulated? How do I get back to the more explicit long-hand format of a property if I need it? At least in VS.NET 2008, after finishing the definition of the property and its type and pressing <enter> the template was generated for me, so how do I recreate this in VS.NET2010?

The answer is to type in 'prop' (without quotes) which will show an Intellisense menu of built in snippets including the needed 'Property' code (shown below):


Type in 'prop' and hit the tab key twice to produce the long-hand explicitly defined version of the Property. In fact even this is 1 up from VS.NET 2008 as it creates the backing variable right on top of the property. All you need to do is tab through the fields to modify the values as needed. The long-hand version of the property is displayed below:

Add SourceSafe Add-In to VS.NET 2010

Ok for those out there that are still way behind on moving to Team Foundation Server and still use SourceSafe, you will find adding solutions to it in VS.NET 2010 is not enabled by default. To switch source control providers back to SourceSafe do the following: Goto 'Tools' -> 'Options' and select "Show all settings". Expand the "Source Control" node and then select "Plug-in Selection". On the right hand side change the value in the "Current source control plug-in:" to "Microsoft Visual SourceSafe" (pictured below).


Then sometime soon consider moving to Team Foundation Server, which has a "Basic" version that allows a route into a new provider for those intimidated by switching away from SourceSafe.