Visual Studio 2012/2013 Page Inspector fails with “Object reference not set to an instance of an object”


I’ve had this problem for as long as I can recall.  My page inspector in Visual Studio 2012 never worked… which normally would have been ok, since I could always do the old-school edit+save+refresh routine… but when you know that the feature exists, it is a bugger that it doesn’t work.

I tried everything, from disabling all my extensions and add-ons, to hooking up a debugger to my devenv process… to the obvious google-and-bing-fu manic searches… but got nothing.

If you check your ActivityLog.xml, you will see that Page Inspector is blowing up with a NullReferenceException… no surprise there.

After installing VS2013 I hoped that all of this would go away, but I got the same error.

Page Inspector fails with Object reference not found
Page Inspector fails with Object reference not found

Finally, I had the great brain wave of setting Internet Explorer as my default browser and restarting Visual Studio (I’m a chrome user).

…and voilà… page inspector finally works :(

One would think that by this time, this whole thing about being wired-in to Internet Explorer was a thing of the past… clearly it is not.

I’ve filed a bug report accordingly on Microsoft Connect.

DM2S63MFEY9G

Advertisements

SetSite failed for package [CctSharedPackage]


I’ve seen this exception way too many times in Visual Studio 11 and 12… turns out that it is an issue with Azure SDK 2.2 – and my google-fu skills failed to find a solution online.

Yet… if you look into your C:\Users\[username]\AppData\Roaming\Microsoft\VisualStudio\11.0\ActivityLog.xml file, you’ll find errors on the lines of:

Could not load file or assembly ‘Microsoft.VisualStudio.WindowsAzure.Diagnostics, Version=2.2.0.0…

The fix turns out to be quite simple, once you see that error.  This just means that the assembly cannot be found… so hey, just add it to your GAC like so:

Add assembly to GAC
Add assembly to GAC

Voila… problems solved.

 

ASP.NET MVC always throws a System.Globalization.CultureNotFoundException


I ran into this problem today.

Being an overly pedantic developer, I was annoyed that my ASP.NET MVC project was always silently throwing this exception on startup.  So I dug into the guts of System.Web.dll to find out ‘why’ this exception was being thrown.

It turns out that upon startup, ASP.NET tries to create the CultureInfo for the project by looking for the good old Satellite directories… so far, so good, this makes total sense.

The issue is more about HOW this is done.

The System.Web.Compilation.StandardDiskBuildResultCache class calls its internal FindSatelliteDirectories method.

This, in turn, fetches all the folders (a.k.a. Directories) that it finds in the Temporary ASP.NET files temp folder, and iterates over them to see if any of them are Satellite Directories.

There is a conditional statement to bypass this check if the folder is called ‘assembly’ or ‘hash’, yet it fails to check if the folder is called ‘UserCache’, which also definitely not a satellite folder.

Personally I think this is bad design in the first place, since:

  1. Satellite folders have a predictable naming convention
  2. Why check for what it is not rather than what it is?
  3. What happens if the developer decides to throw in another 5 folders? This would be an extra 5 exceptions being thrown… and nobody likes the computational cost of exceptions.

I really wish Microsoft would fix this… until then, we’re going to have to live with seeing a bunch of ‘System.Globalization.CultureNotFoundException’ on startup :(

Note: the System.Web.dll that I am checking is v4, and the one that comes with .NET Framework v4.5

 

Setting CSharp (C# / CSC.exe) Compiler Defaults


A little known secret about the .NET C# Compiler (CSC.exe) is that it allows us to set ‘global defaults’.

To do this, create a text file called CSC.rsp in one of two places:

  • The current directory (handy for project specific settings)
  • The directory where CSC.exe is stored
    (generally found in C:\Windows\Microsoft.NET\Framework\{version}\csc.exe)

Note that local settings (current directory) will override the global settings.  Also note that there already exists a global CSC.rsp file with the common ‘includes’, you can either add to this, or simply add a setting to this global file that also includes a secondary settings file (more below).

Any command-line switches that you would normally pass to csc.exe can be added in this text file.

If you do not want these settings to be global, but you want to still supply settings in a text file (handy for multi-project settings which you only want to update in one place), just add them to a different named text file and add a command-line argument to csc.exe like so:

csc.exe @{path\to\settings\file.txt} …

If on the other hand you want to explicitly ignore any local or global settings file, simply run csc.exe using the /noconfig argument.