How to assert SqlClientPermission(PermissionState.Unrestricted) if 2.0 installed?

I have a winforms control hosted in IE on my site that needs to access my SQL Server database.

I was able to do this by granting it full access using the 1.1 wizards and asserting permission around the code by calling...

   SqlClientPermission perm = new SqlClientPermission(PermissionState.Unrestricted);
   perm.Assert();

....

   CodeAcces****ission.RevertAssert();

Now, ever since i installed the 2.0 framework, my 1.1 dll no longer works.

Apparently the browser will run the latest version installed so if my client has 2.0 and 1.1 installed, my code gets loaded via 1.1 no matter what i do.

So... how do i allow my dll to connect to the Sql server if 2.0 is installed And will this still compile use VS 2003 and will it still run if only 1.1 is installed on my client's machine
And are these security differences in 2.0 documents anywhere

Len.

.NET Development2

I looked at this further and came to the conclusion that i may not be trusting the dll properly anymore if 2.0 is installed.
If i use the 1.1 wizards to trust an assembly (full trust) but for some reason the assembly gets loaded by 2.0, does 2.0 also automatically trust if with full trust

So, i went into the 2.0 configuration, searched through it to find the equivalent of the 1.1 trust an assembly wizard, and entered the url to the dll.

BUT, i get an error. "Hash for the assembly cannot be generated."
So 1.1 can trust the dll, but 2.0 cant even try Is that because it was compiled for 1.1 Or because its not signed with a strong name (i havent had to so far in 1.1).

Do i need to compile a version of my dll for 2.0 using VS 2005 C# Express and point to the correct file based on what their browser says is the version of .Net they have installed (all so they can trust the dll). Or has 2.0 broken things so that i finally need to sign my dll (real pain when attempting to debug if i have to sign on every compile).

Len.

This is getting really frustrating!
I went in with the 1.1 wizard, and viewed the permissions on the assembly and it has full trust.
I went in with the 2.0 wizard the same way. and it has the normal minimum trusts.
(so 1.1 trusts dont migrate to 2.0, how stupid).
But when i use the 2.0 wizard to trust the assembly it fails saying it cannot generate a hash (how about changing this tool to give a real error! ie why.)
So while reading the various help topics, i figured maybe the 2.0 security is picky about having a strong name.
So i generated a key pair using sn.exe, and put the path to it in the AssemblyKeyFile tag.
Then i went in and retrusted the assembly in 1.1
Then i went into 2.0 and tried to trust it, and lo and behold, no error about hash.
(would be nice to see this documented as something that was changed from 1.1 to 2.0!)
So, i went to my web page to see if the hosted control would work.
BUT NOW... it wont even load. The first line of my control brings up a debug messagebox (which did display before adding a strong name) and it wont appear.
So adding a strong name and full trusting the assembly made it work EVEN LESS!

I cannot believe i am the only person having this problem with hosted controls once 2.0 gets installed.
Is this change in behavior documented ANYWHERE
Is anyone from ms even reading this newsgroup
Len.

Well i seem to be talking to myself alot in this thread.
I almost think this is a blog.

But I GOT IT TO WORK.

Here is my results on this tedious issue.

1. If you have an assembly that works in 1.1, be carefull if it gets loaded in 2.0 since it might not work.

2. If your assembly was trusted in 1.1, and is forced to load in 2.0, it wont be trusted unless you run the 2.0 wizards or 2.0 caspol too.

3. The 2.0 trust wizard will not trust an assembly without a strong name. Instead it gives an error of "Cannot generate Hash"

4. If a hosted control has a strong name, it will not load in Explorer unless you add [assembly: AllowPartiallyTrustedCallers()] (possibly only if 2.0 installed). If it does not have a strong name, you do not need AllowPartiallyTrustedCallers (unless you script the control via events which does require AllowPartiallyTrustedCallers).

5. If you want to assert permissions in a hosted control, and you want to support someone who has 2.0 installed, you MUST include a strong name via AssemblyKeyFile, you MUST trust the assembly using 2.0's trust tools too, and you MUST include AllowPartiallyTrustedCallers.

This really should be in a FAQ somewhere in MSDN's security section.

Len.

I too have this problem with an application I have built. Under 1.1 I can give it full trust, but with 2.0 I can't.

I only want the application to access local network drives. Do I have to give the application a strong name as this is rather tedious

I have also found IE7 has started poping up File Security warnings when opening source files with a text editor of my choice. Oh it's so nice that Microsoft are slowing me down at every corner, soon I won't be able to do anything!!