The host I'm using (1&1) has a rather restrictive set of policies.

The following functionality will not be available in a protected environment: - Classes that explicitly demand FullTrust like classes in namespaces "System.Data.OleDb" and "System.Data.Odbc". - Pre-installed Assemblies in Global Assembly Cache (GAC), that are not marked with Attribute "AllowPartiallyTrustedCallers", e. g. "System.EnterpriseServices.dll". - Custom, uploaded assemblies that carry a "StrongName" but are not

marked with Attribute "AllowPartiallyTrustedCallers"

After removing all references to these restricted libraries. (I think) I recompiled everything and still got the very ambiguous "System.Security.SecurityException: Security error." Which is the usual error for these security problems. Then I realized that the two support classes (SD.LLBLGen.PRO.*) have strong names as well. I checked them using ildasm.exe, and sure enough, no AllowPartiallyTrustedCallers attribute.

My question is this: Is it possible to use LLBLGen under those restrictions, or would I be better off switching to a different host and hassling these guys for my money back.

Security is Fun

Your llblgen pro installation comes with the sourcecode of the runtimes. Remove the key path from the assemblyinfo files and compile the code using the scripts. Then recompile your generated code and own code with these own compiled runtime libs.

I'll check the attribute and will add it to the runtime library if it doesn't break code currently in production.

(edit) huh? requiring this attributes makes security WEAKER, not stronger.

I know it makes things weaker, but since ALL of my assemblies don't have strong names / aren't fully trusted (including ones I have no control over) I have to compile all the ones I do have control over with this attribute. Having said that, I didn't know that I had the source to those two assemblies I needed to change. I can just add this attribute to MY personal version; there's no reason to add it to your release version.

Ok

I also don't think I'll add that attribute, as it makes security weaker by definition for the runtime libraries, which is not what I want.

I've added this attribute to the runtime libraries for .net 1.1 and .net 2.0. It's available in the next build.

Thanks for doing this, it will save me the trouble of re-building your source every time a new version comes out.

You're right, it weakens everything to the same point that existed prior to .NET 2.0. I think Microsoft's intent was to create a 'possibility' of everything being secure, knowing it would not realistically be implemented. By creating that possibility they shift the burden (and liability) for securing code from themselves to individuals and companies. It's a risk I have to take in order to make things work, and it's no worse a risk than already existed prior to this version of .NET.

After I saw the attribute is on almost every .net assembly I thought it wouldn't be a problem. A developer can always limit the access to the actual generated code by applying other attributes to that assembly.

I'm having a similar problem with the System.Security.SecurityException. It happens within my generated code at this line:

FlatlandMedia.NinjaRoutes.Dal.DaoClasses.RegionDAO..ctor() in RegionDAO.cs

I'm a novice at using ildasm, but I took a look at the two strong-named assemblies that I'm referencing. SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll has this in its manifest:

.custom instance void [mscorlib]System.Security.AllowPartiallyTrustedCallersAttribute::.ctor() = ( 01 00 00 00 )

However, SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll does not have this reference in its manifest. Am I missing something? BTW, here's my ISP's policy:

The custom setting is basically medium level with some exceptions including ODBC, OLEDB, Reflection Permissions and Web Permissions. This setting cannot be overridden.

Here are the permissions granted by the medium trust level:

Medium Permissions are limited to what the application can access within the directory structure of the application. No file access is permitted outside of the application's virtual directory hierarchy. Can access SQL Server Can send email by using SMTP servers Limited rights to certain common environment variables No reflection permissions whatsoever No sockets permission To access Web resources, you must explicitly add endpoint 'URLs' - either in the originUrl attribute of the element or inside the policy file.

The following exceptions have been granted in addition to the ones listed above:

ODBC OLEDB Reflection Permissions Web Permission

Thanks for the help, Pete

It should have that attribute. I'll check the code.

(edit): the DQE's don't have the attribute. I'll add that, will be available in the next build.

Samething for the Mysql DQE.

Can you add it please? I'm waiting for this to update a website .

Thanks

matlaf wrote:

Samething for the Mysql DQE.

Can you add it please? I'm waiting for this to update a website .

Thanks

It will be available tonight.

It's uploaded.

Great! The newly uploaded dlls work great on my hosting provider. Thanks!