Interesting Findings, we'll investigate this a little bit more. Thank you.

Deividas wrote:

I think I found the cause of the problem. It is probably the fact that I downloaded the runtime lib from the forum. Therefore it was marked as untrusted. More info here: http://blogs.msdn.com/b/friis/archive/2010/06/09/system-security-securityexception-request-for-the-permission-of-type-system-web-aspnethostingpermission-failed.aspx . Although unblocking the file didn't solve my problem, setting the application pool to LocalService did (NetworkService also works), which is an acceptable solution for me.

Interesting! I never knew that, and it explains indeed the problems you had

So the moral here is that you use a bad practice - attaching dlls to forum posts. Although that is nothing to be ashamed of, I guess. I didn't know about it before either.

We thought about sending CD's out through UPS, but it turned out to be quite a challenge

Anyway, we did thought about this a bit, and we decided to add a fall-back scenario for the people who can't use these config files in production but need medium trust: a setting which falls back to propertyInfo.SetValue(..) and not the generated IL based setter. It's slower, but not that much slower that it will bring things down to a crawl (as it's web stuff, the latency of the HTTP protocol likely will mask it). This will be a web.config setting for v3.1.

We thought about sending CD's out through UPS, but it turned out to be quite a challenge

I think sending files through email would be sufficient. Or informing the customers that they have to unblock the files as soon as they download them.

I wonder if the problem would go away if you zipped the dll's and attached the zips to the post?

Zip is indeed a good idea: unpacking the zip will create a file with the credentials in the zip, not what the browser set. Still I think it's an odd thing that this happens though, especially because where in the filesystem is this information stored? It can also be that the dll is referenced from a share, which gives the same problem.

About unblocking: we only knew about that issue with .chm files, but not about dlls (I still find it strange)

Zip is indeed a good idea: unpacking the zip will create a file with the credentials in the zip, not what the browser set.

Not true. When unzipping, the individual files will be marked as the same zone as the zip file.

where in the filesystem is this information stored?

It is stored in NTFS. And copying such file to another computer with NTFS copies the property too.

Deividas wrote:

Zip is indeed a good idea: unpacking the zip will create a file with the credentials in the zip, not what the browser set.

Not true. When unzipping, the individual files will be marked as the same zone as the zip file.

I have a hard time believing that e.g. 7zip will set those properties. Do you have a URL for more info on this? 7zip sets the file properties INSIDE the zip file, not of the zip file itself. Maybe it does though, I haven't tested it, but I do think it's a windows/IE/explorer specific feature (as 7zip too doesn't know anything about 'internet zone' (or other security zone), just file ACLs

where in the filesystem is this information stored?

It is stored in NTFS. And copying such file to another computer with NTFS copies the property too.

Hmm... ok, but is Firefox for example setting those properties on a file downloaded? Did you use IE or another browser? I ask this because Firefox doesn't have the concept of 'internet zones', IE does.

Otis wrote:

Deividas wrote:

Zip is indeed a good idea: unpacking the zip will create a file with the credentials in the zip, not what the browser set.

Not true. When unzipping, the individual files will be marked as the same zone as the zip file.

I have a hard time believing that e.g. 7zip will set those properties. Do you have a URL for more info on this? 7zip sets the file properties INSIDE the zip file, not of the zip file itself. Maybe it does though, I haven't tested it, but I do think it's a windows/IE/explorer specific feature (as 7zip too doesn't know anything about 'internet zone' (or other security zone), just file ACLs

I don't know how it works, but people say that files are being marked untrusted when unzipped. There's some more info here but not much: http://superuser.com/questions/38476/this-file-came-from-another-computer-how-can-i-unblock-all-the-files-in-a .

where in the filesystem is this information stored?

It is stored in NTFS. And copying such file to another computer with NTFS copies the property too.

Hmm... ok, but is Firefox for example setting those properties on a file downloaded? Did you use IE or another browser? I ask this because Firefox doesn't have the concept of 'internet zones', IE does.

I used Firefox. Emule, Live Messenger and probably other programs are affected by this too.

Edit: Clearly this is done on OS level, no one would code such thing in Emule.

Must be something in Vista / 7, as on XP no NTFS stream is set when downloading a file from the internet.

Anyway, as we can't do a thing about it, it's the way it is (you're the first btw who reports this), people have to unblock the file, which is a thing they have to do anyway for files downloaded from the internet or in email (as that wouldn't be any different IMHO).

Thanks for the info on this.

Must be something in Vista / 7, as on XP no NTFS stream is set when downloading a file from the internet.

Well, at least some of Windows XP SP2 machines are also affected. Several posts on internet state that.

Deividas wrote:

Must be something in Vista / 7, as on XP no NTFS stream is set when downloading a file from the internet.

Well, at least some of Windows XP SP2 machines are also affected. Several posts on internet state that.

You have to make a difference between downloading a file from the internet locally and then open it, vs. downloading a file from a share. The former doesn't work on XP sp3, I just tried: no problems. When I open / use a file across a network share (e.g. mapped drive!) you get this problem, as the source is 'untrusted' at the OS level.

I don't know if you have downloaded the file to a mapped drive, and then used it, as that will give the problem as well on XP. Anyway, it's not LLBLGen Pro related, so I'll leave it at this.