Azure Aftermath

After the mess with the Azure SDK reserving ports that conflicted with my development environment, and the fact that the SDK didn’t do anything for the automated publishing I was looking for, I decided to uninstall it.  Well, that wasn’t a good idea.  You could say it was “Azure disaster.”

First off, the uninstall of the multiple elements of the Azure SDK did not remove the NETSH entries for the Azure Storage Emulator. so those had to be manually removed. Then, I reopened VS 2013 and suddenly none of my web projects open, saying they are all incompatible with this version of Visual Studio.  I tried to create a new web application and got the useful error:

image

So now I can’t open or create any web applications in Visual Studio.  I decide I should reinstall the Azure SDK to put back what was taken away, although in my mind I realize this is a ridiculous concept.

I download the SDK and run it.  I then get this error from the installer:

image1

Absolutely incredible.  This is like dealing with anti-psychotic medication.  “Whoa whoa whoa, you just can’t uninstall Pericyazine, that can cause a psychotic episode.”

Next thing to do is a Repair of the Visual Studio installation, which is going to be at least an hour…  And that has fixed the web project issue, so at least uninstalling the Azure SDK is recoverable.  You just need to make sure you manually get rid of the ACL entries with these statements (at an Administrator command prompt):

netsh http delete urlacl url=http://127.0.0.1:10000/
netsh http delete urlacl url=http://127.0.0.1:10001/
netsh http delete urlacl url=http://127.0.0.1:10002/

Yes, I do believe when Windows 10 and VS 2015 come out, this work machine is due for a reformat.

IISExpress – Error description: Access is denied. (0x80070005)

Today, I spent my entire work day trying to find the solution to this error.

When I would launch a web project from Visual Studio, IIS Express would fail to load.  The error reported was:

Failed to register URL "http://localhost:10000/" for site "Portal3" application "/". Error description: Access is denied. (0x80070005)

I started down the obvious track of checking permissions.  IISExpress would operate just fine when run as Administrator, but not as my normal user.  I was an administrator on the local machine, so that didn’t make any sense.

The only thing I had done that morning was use Disk Cleanup to delete all my temp files and archived error reports.  I checked %temp%\iisexpress.  I checked my *.config files in Documents\IISExpress over and over.  I restored configs from backups.  I read many potential solutions, some as crazy as not being able to use a user name with “bg” in it.

I tried an older iteration of the web application.  It worked.  I tried other web projects in the solution.  They worked.  At this point, I was the only developer in my team who had a single web project that wouldn’t launch.

Then, late as usual, I finally remembered the Windows Event Viewer.  IISExpress was logging these two events:

Event ID: 2269: The worker process for app pool ‘Clr4IntegratedAppPool’, PID=’7536′, failed to initialize the http.sys communication when asked to start processing http requests and therefore will be considered ill by W3SVC and terminated.  The data field contains the error number.

EventID 2276: The worker process failed to initialize correctly and therefore could not be started.  The data is the error.

That lead me down a totally different troubleshooting path.  While doing so, I set up a new website in IIS on port 8085.  Oddly, my new websites and application pools didn’t refresh after being created, which led me to think there was even more wrong with my workstation.  An IISRESET resolved that problem and I was able to browse to the web project using IIS.

So IIS would work on port 8085 but IISExpress would not work on port 10000.  And IIS would work for any other project on seemingly any other port. 

In a comment on one of the web posts that I read, I saw this command:

netsh http add urlacl url=http://localhost:10000/ user=everyone

I’d only ever used NETSH maybe once or twice for some obscure reason, but the inclusion of “ACL” in the command was encouraging.  Amazingly, the command worked!  Although I was happy, I was also disappointed that I wouldn’t be able to see what the value was previously so I could find out the root cause.

So I ran:

netsh http show urlacl

And that displayed a bunch of entries that included these as well (User and SDDL changed):

Reserved URL            : http://127.0.0.1:10000/
    User: Me 
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-21-)

Reserved URL            : http://127.0.0.1:10001/
    User: Me
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-21-

Reserved URL            : http://127.0.0.1:10002/
    User: Me
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;S-1-5-21-)

Where did these come from?  I ran netsh http delete urlacl url=http://localhost:10000/ and removed the entry and confirmed IISExpress stopped working.  Then I ran netsh http delete urlacl url=http://127.0.0.1:10000/ and IISExpress started working again.

Something had added ACL entries for ports 10000-10002 that were conflicting with my web project, which was trying to run on port 10000 using IISExpress.  How did they get there?  I looked in Add/Remove Programs to get a clue as to what could have added these entries.  Who’s to blame?  The Azure SDK.  Azure Storage Emulator uses ports 10000-10002 and creates reservations for them.  This was installed during my attempts at getting command-line Web Publishing to work.

I never would have known anything about this unless I had read the Azure SDK documentation.  The error message I was given said nothing about port conflicts.  nothing led me down that path at all.  And it’s entirely possible no one else would have this problem unless they were running IISExpress on port 10000.

But the important takeaway from this is that NETSH will allow you to create reservations for port numbers that may conflict with other applications.

SSRS ReportViewer NullReferenceException on Dispose

I recently assisted on troubleshooting an error in a utility application where an exception was being thrown on the dispose of a Microsoft.Reporting.WebForms.ReportViewer.  The environmental conditions were pretty specific, so it’s possible you’d never see something like this in your environment.  But if you do, here’s how you can work around it.

The specific condition is that we have a shared library of code for both desktop and web applications.  One of the functions in that library takes some parameters for an SSRS report and returns a byte array for a rendered PDF of the report.  Because the library initially was used exclusively by the website, the WebForms version of the ReportViewer was used.  As time went on, the library was used by desktop apps and windows services.  That’s when the trouble began.

So, if you are using a WebForms.ReportViewer in a desktop application, you may get this exception when disposing the instance.  Digging into the decompiled code for the ReportViewer control suggested it was because there was no HttpContext available.  For us, the long-term fix was clear: use the WinForms version of the ReportViewer.  In the short term though, adding this line of code resolved the error:

If HttpContext.Current Is Nothing Then HttpContext.Current = New HttpContext(New HttpRequest(IO.Path.GetRandomFileName, "http://www.google.com", ""), New HttpResponse(IO.TextWriter.Null))

This created an HttpContext where there was none before, and the ReportViewer instance was able to be disposed without an error.