Deividas wrote:
that's odd. Also, what I described only works if you define a different trustlevel (e.g. custommedium) and set that as the trustlevel. I was able to make the exception go away when I did that, hence my suggestion to follow that.
It didn't work for me. I know that the security policy file was read, because otherwise exception would have been thrown.
well, there must have been something wrong, as it did work here. The problem is that you have to make sure the additional flags are indeed added. It also might be the runtime lib you're using is outdated, but if you're using the one I attached today to your bugreport, it is the latest build. I had a hard time getting it to work as well, but eventually when I did everything I described above, it worked out.
It might be that the hosting provider forces a trustlevel on you, but I don't know if that's possible (IMHO it should be possible to override that trustlevel in the config file, according to documentation)
I don't use a hosting provider. It's a machine used for development purposes with default settings. Also I don't know if that changes anything but I use WCF.
No idea. You specified full trust in the config file and still it didn't work, which IMHO means the trust level in the config file wasn't read. What trust level did you set in IIS?
Also don't you think that requiring your customers to change trust levels is a little bit too much? I don't think any other ORM tools do that. Otherwise, a great product.
The problem is that our code is now using DBProviderFactory. This means that we've to set the ado.net provider specific dbtype enum property on the parameter object somehow without a reference to the particular ado.net assembly (otherwise, why bother with providerfactory). This is doable, but that can be done only by using a delegate. As our code is compiled on .net 2.0 to make it work on .net 2.0 as well, we can't use a func<>, so we have to use a real delegate on a type coming from another assembly (the ado.net assembly we grab from the factory). A delegate is really slow compared to a dynamic method generated at runtime, so we use that instead. This has the downside that we have to create a dynamic method on a type coming from outside the codebase, which gives the security exception. When I add the flag to the trustlevel as described to allow that, it works.
So it's not really something we can fix without a serious compromise (and the delegate will be called a lot (every parameter created) which means it has significant impact)...