aspnet_regiis “Could not load file or assembly ‘SimpleAuthentication.Core’ or one of its dependencies.”

I was recently following Jouni Heiknieme’s blog post on Encrypting connection strings in Windows Azure web applications when I stumbled across a problem.

The issue was that I wasn’t encrypting the connectionStrings section, I was encrypting a custom section (one provided by SimpleAuthentication). And in order to encrypt that section, aspnet_regiis needs access to the DLL that defines the config section. If it cannot find the DLL it needs it will respond with an error message:

C:\dev\Xander.HorribleCards\src\Xander.HorribleCards.UI.Web>aspnet_regiis -pef "authenticationProviders" . -prov "Pkcs12Provider" 
Microsoft (R) ASP.NET RegIIS version 4.0.30319.18408 
Administration utility to install and uninstall ASP.NET on the local machine. 
Copyright (C) Microsoft Corporation.  All rights reserved. 
Encrypting configuration section... 
An error occurred creating the configuration section handler for authenticationProviders: Could not load file or assembly 'SimpleAuthentication.Core' or one of 
its dependencies. The system cannot find the file specified. (C:\dev\Xander.HorribleCards\src\Xander.HorribleCards.UI.Web\web.config line 7) 
Could not load file or assembly 'SimpleAuthentication.Core' or one of its dependencies. The system cannot find the file specified. 
Failed!

And here is the relevant part of the web.config file

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
  <configSections> 
    <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"> 
      <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" /> 
    </sectionGroup> 
    <section name="authenticationProviders" type="SimpleAuthentication.Core.Config.ProviderConfiguration, SimpleAuthentication.Core" /> 
  </configSections>

It took searching through a few forum posts before I eventually found the answer. Most were pointing in the right general direction. You either have to load the assembly that defines the config section into the GAC (not possible for me as it was a third party assembly that was not strong named) or put it where aspnet_regiis was looking for it.

All the non-GAC solutions that I found were hacky horrible things that put the assembly somewhere in the .NET folder.

My problem was that where everyone was saying to put it wasn’t working for me. So I loaded up Process Monitor to look to see where exactly the aspnet_regiis was looking. It turns out that because I was using the 64bit version of the command prompt I should be looking in C:\Windows\Microsoft.NET\Framework64\v4.0.30319

I put the assembly in that directory and the aspnet_regiis worked and the relevant section was encrypted, it was runnable and I could store it to source control without other people knowing what my secret keys are.

Round tripping the encryption/decryption

I also had some issues round tripping the encrypted and decrypted config file while developing. I kept getting the error message:

Decrypting the relevant config settings
Microsoft (R) ASP.NET RegIIS version 4.0.30319.18408
Administration utility to install and uninstall ASP.NET on the local machine.
Copyright (C) Microsoft Corporation.  All rights reserved.
Decrypting configuration section...
Failed to decrypt using provider 'Pkcs12Provider'. Error message from the provider: Keyset does not exist
 (C:\dev\Xander.HorribleCards\src\Xander.HorribleCards.UI.Web\web.config line 65)

Keyset does not exist

Failed!

It turned out to be a permissions issue on the private key. This post “Keyset does not exist” on Stack Overflow helped on how to resolve that.

Internal Error 2755 caused by folder encryption

I was attempting to install some software recently (a few hours ago, actually) and I kept getting a message saying “The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755.” while installing the software. So I searched the internet for an answer and came up with all sorts of links:

Anyway, most seemed to suggest that the problem lay with incorrect permissions being set on the file system. So, I went through the file system and checked the permissions as per the Microsoft knowledge base article detailing the problem with the Office 2000 installation. Everything set correctly, I tried again. No luck.

I burned the MSI file to a CD and it worked (CDs don’t use NTFS and its permission system). So, it was something definitely to do with the permission sets.

I downloaded FileMon from the SysInternals website so have a look further at what it was doing. I discovered that it was getting an Access Denied on a file in the Temp directory. (The setup program dumped an MSI file in the temp directory during installation) The problem was, it appeared to be attempting to open the file as NT_AUTHORITYSYSTEM. That account has more rights than the Administrator account, it basically is an Access All Areas account… And it was being denied access!

After some further experimentation, including restoring a system checkpoint back a couple of days, it still wasn’t working. Then I noticed that the temp folder was green which indicates that the contents were encrypted. (I experimented with file encryption a few months ago and had since forgotten about it).

To cut a long story short, I removed the encryption flag on the Temp directory (and spent a couple of minutes waiting for it to decrypt everything) and tried the installer again. It worked!

I don’t know why the fact the folder was encrypted had anything to do with it, but it worked once decrypted. Weird….

NOTE: This entry was rescued from the Google Cache. The original date was Sunday, 15th October, 2006.

Tags:


Original comments:

Windows Installer works in two phases – an ‘immediate’ phase in which it generates a script for what to do, and a ‘deferred’ phase in which it actually does the installation. The immediate phase runs under the launching user’s credentials, but the deferred phase is run by the Windows Installer service, which runs as LocalSystem.

If the script is written into an encrypted folder, it will be encrypted using your encryption key. The service, running as LocalSystem, will not have this key, or the recovery key (which is owned by the administrator) and will be unable to read the script.

10/15/2006 12:16 PM | Mike Dimmick