Unverifiable assembly 'mmsseclib' failed policy check

onovotny · Post by **onovotny** » Fri Mar 19, 2004 9:58 am

After installing Vault 2.0.1, I am running into problems executing the web services (which prevents anything else from functioning).

I am running Windows Server 2003 EE (with IIS6) and .NET 1.1.

The error message I'm getting is:
Unverifiable assembly 'mmsseclib' failed policy check

With a pointer to machine.config line 199. The only thing there on line 199 was an add assembly=* type of thing.

Examining the mmsseclib.dll shows that it's a mixed-mode MC++ file that uses native code too. I suspect that the default settings of ASP.Net prevent native (unverifiable) code from running. What's the correct way to grant permission for this so I can run the service?

Thanks!
--Oren

Post by **jclausius** » Fri Mar 19, 2004 10:22 am

oren:

have you run iislockdown? this error message is common after running iis lockdown on your web server.

if this is the case, you can either:

rename the file to mmsseclib.dll.old
just delete the file

onovotny · Post by **onovotny** » Fri Mar 19, 2004 11:14 am

I've found the solution to the problem. The following line needs to be added to the system.web section of the web.config. Once that's done, all of the security issues are resolved (as you are now running in full trust). Perhaps that should be added to the default web.config to prevent others from running into this problem?

<trust level="Full" originUrl="" />

Also, for whatever reason, the installer didn't correctly create/update the keys in the appSettings section, but using what was there, I was able to fix it.

Regards,
--Oren

Post by **jclausius** » Fri Mar 19, 2004 1:29 pm

Also, for whatever reason, the installer didn't correctly create/update the keys in the appSettings section, but using what was there, I was able to fix it.

oren:

can you elaborate on this?

[/quote]

onovotny · Post by **onovotny** » Fri Mar 19, 2004 2:44 pm

Well, the ConfigPath still had a value of:

C:\BuildLab\v2342\vault.config -- I forget the default, but it wasn't any path on my machine; it must be whatever the default was.

The Connection string key wasn't there at all; the only thing that was there were the two templates, one for windows auth and one for sql auth.

Post by **jclausius** » Fri Mar 19, 2004 3:55 pm

oren:

i'm assuming you saw information like:

<add key="configpPath" value=c:\vaultbuild\SOME_BUILDNUMBER\Service\vault.config." />

you've confirmed my suspicions - the installation has really failed. unfortunately, the installer has a couple of "snafus", that seem to be related to bugs within the wise installation framework itself.

if you feel your server is working correctly, then you can continue working and ignore the rest of this message.

however, if you do encounter problems, i would suggest the following steps:

uninstall your current vault server implementation.
(a) the most common error is installing on a machine that *had* a previous version of microsoft .net - for example, uninstalling the 1.0 framework, and installing the 1.1 framework. when the custom section of the installation runs, the installer framework incorrectly finds an empty microsoft .net 1.0 folder. (i.e. %windows%\microsoft.net\framework\v1.0.3705). you can identify if you encountered this problem from a run of a previous installation. during your first installation, were you prompted to connect to sql server? if so, the installation should have asked you to log in, and it would have "popped" up a progress window displaying it was creating the database schema. did any of these events occur?

if you were not prompted for a database login, the work-around is to simply rename the empty microsoft .net folder by placing a string - say "yyy" -as the prefix. for example, rename the folder to %windows%\microsoft.net\framework\yyy_v1.0.3705. then re-run the vault server installation.
(b) if during the previous installation you *were* asked to log into sql server. it is very important you login with *full* administrative rights and full access to the master database. during this phase, the installation script will execute CREATE DATABASE, ALTER DATABASE to set options, and create the entire schema. it is a reported bug that using a sql login with less than administrative rights will cause the installation to fail internally, although it appears to the end user that the installation was successful.

if this was the case, please make sure the account you use to log into the sql database has administrative rights.

thanks,

onovotny · Post by **onovotny** » Fri Mar 19, 2004 4:22 pm

jclausius wrote:oren:

i'm assuming you saw information like:
<add key="configpPath" value=c:\vaultbuild\SOME_BUILDNUMBER\Service\vault.config." />




you've confirmed my suspicions - the installation has really failed. unfortunately, the installer has a couple of "snafus", that seem to be related to bugs within the wise installation framework itself.

Yes, that's exactly what I saw.

jclausius wrote:]if you feel your server is working correctly, then you can continue working and ignore the rest of this message.

however, if you do encounter problems, i would suggest the following steps:
uninstall your current vault server implementation.

(a) the most common error is installing on a machine that *had* a previous version of microsoft .net - for example, uninstalling the 1.0 framework, and installing the 1.1 framework. when the custom section of the installation runs, the installer framework incorrectly finds an empty microsoft .net 1.0 folder. (i.e. %windows%\microsoft.net\framework\v1.0.3705). you can identify if you encountered this problem from a run of a previous installation. during your first installation, were you prompted to connect to sql server? if so, the installation should have asked you to log in, and it would have "popped" up a progress window displaying it was creating the database schema. did any of these events occur?

I have both the 1.0 and 1.1 framework installed; I have not removed either. Default assembly binding policy should be the latest version, unless the config file says otherwise -- like the sourcegear server service does.

jclausius wrote:if you were not prompted for a database login, the work-around is to simply rename the empty microsoft .net folder by placing a string - say "yyy" -as the prefix. for example, rename the folder to %windows%\microsoft.net\framework\yyy_v1.0.3705. then re-run the vault server installation.

[*] (b) if during the previous installation you *were* asked to log into sql server. it is very important you login with *full* administrative rights and full access to the master database. during this phase, the installation script will execute CREATE DATABASE, ALTER DATABASE to set options, and create the entire schema. it is a reported bug that using a sql login with less than administrative rights will cause the installation to fail internally, although it appears to the end user that the installation was successful.[/list]

if this was the case, please make sure the account you use to log into the sql database has administrative rights.

I was prompted to create the sql server database and in both instances used Windows Authentication. Here's the catch, and it's something you'll want to troubleshoot--I would try to help, but since the functions are all encrypted

I can't be of assistance -- the scripts you use fail on Yukon. I have attempted to install Vault many times while trying to get everything working... I have Yukon installed as well as an MSDE2000 instance; when I use the MSDE2000 instance the script works, but on Yukon it does not. Something about an improper use of an "UPDATE" statement not being allowed someplace. The interesting thing is that thigns appear to work if I detach the database from MSDE and bring it over into Yukon... but I don't know if the function will run since I don't know which function has that code nor know how to call it

For the rest of this discussion though, I'm using the MSDE2000 instance as the database, not Yukon. I have also explictly set the script maps to the 1.1 framework for the IIS application, using the aspnet_regiis tool, so as far as the web applications are concerned, they are oblivious to any other framework versions.

I'd be happy to work with you further; feel free to email me and we can continue this off-line. Vault appears to be a great product, but so far it's been a huge hassle to get running (see my other thread). SourceOffSite "just works."

Regards,
--Oren

Post by **jclausius** » Fri Mar 19, 2004 4:40 pm

oren:

sorry you're experiencing problems. however, we do not support vault on beta releases of software. this includes longhorn, whidbey, and yukon. i hope you can understand.

its not that we don't want to support these platforms, but these tools are in such a state of flux, it becomes just too difficult to support these moving targets.

as things start to firm up for the release date for whidbey/yukon , we'll start looking at the issues. from your post, it seems like you are volunteering for the beta version of vault to support these platforms

i'll keep your name available for future reference. our goal will be to have a working version of vault for yukon/whidbey a month or so before the platform rtm.

Guest · Post by **Guest** » Fri Apr 16, 2004 4:42 am

jclausius wrote:oren:
it seems like you are volunteering for the beta version of vault to support these platforms

i'll keep your name available for future reference. our goal will be to have a working version of vault for yukon/whidbey a month or so before the platform rtm.

You can add me to that list aswell

Jesse

SourceGear Support

Unverifiable assembly 'mmsseclib' failed policy check

Unverifiable assembly 'mmsseclib' failed policy check

Solution