"Assembly does not allow partially trusted callers" in shared environment

[ilog2000]

Hello,

I tried to utilize Spark engine in a simple scenario. It works on
local computer but fails to run in shared environment. Adding
attribute AllowPartiallyTrustedCallers to CommonAssemblyInfo.cs
doesn't help. The same negative result gives Nant when running

nant -D:assembly.allow-partially-trusted-callers=true

(this way helped me with NVelocity).

Have such a problem been ever resolved by anyone?

Thank you.

[Justin Chase]

It's generating an assembly on the fly based on your views, honestly I doubt this will ever be medium trust compatible (shared environment). It would be possible to create a DynamicMethod using IL emittance instead of the CodeDom to compile the views in medium trust... but IL emittance is much much harder. It would be faster too though...

--
Justin Chase
http://www.justnbusiness.com

[Louis DeJardin]

Yeah... It'd be essentially impossible without recreating the csc
compiler from scratch.

I believe aspview and maybe nhaml get around this problem by
precompiling views into a bin deployable assembly. So this could be
another +1 on that feature.

[ilog2000]

Justin, thanks for the response!

I can argue only with the fact, that NVelocity is doing essentially
the same, but there is a way to overcome the issue. The same I can say
about NHaml, although not for sure - I did not finish digging in it.

BTW, Andrew Peters also switched in the latest version of NHaml to
Reflection.Emit with a delegate instead of Activator usage (
http://code.google.com/p/nhaml/ ). This code looks not so complex for
me. But, pleaase, divide what I'm saying by 2 - I am not a code
generation professional...

[ilog2000]

Louis, sorry, we probably were responding simaltaneously, so, I did
not mention your answer. My thanks to you as well.

On Aug 21, 7:22 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Yeah... It'd be essentially impossible without recreating the csc
> compiler from scratch.
>
> I believe aspview and maybe nhaml get around this problem by
> precompiling views into a bin deployable assembly. So this could be
> another +1 on that feature.
>

> On 8/21/08, Justin Chase <justin.m.ch...@gmail.com> wrote:
>
>
>
> > It's generating an assembly on the fly based on your views, honestly I doubt
> > this will ever be medium trust compatible (shared environment). It would be
> > possible to create a DynamicMethod using IL emittance instead of the CodeDom
> > to compile the views in medium trust... but IL emittance is much much
> > harder. It would be faster too though...
>

> > On Thu, Aug 21, 2008 at 2:24 AM, ilog2000 <ilog2...@gmail.com> wrote:
>
> >> Hello,
>
> >> I tried to utilize Spark engine in a simple scenario. It works on
> >> local computer but fails to run in shared environment. Adding
> >> attribute AllowPartiallyTrustedCallers to CommonAssemblyInfo.cs
> >> doesn't help. The same negative result gives Nant when running
>
> >> nant -D:assembly.allow-partially-trusted-callers=true
>
> >> (this way helped me with NVelocity).
>
> >> Have such a problem been ever resolved by anyone?
>
> >> Thank you.
>
> > --
> > Justin Chase

> >http://www.justnbusiness.com- Hide quoted text -
>
> - Show quoted text -

[Louis DeJardin]

No problem. :)

NVelocity has an advantage in that it's parsing templates to an
in-memory model and rendering from that, so doesn't generate any code
to compile and load.

The kicker is the engine relies so much on the csharp language for
template expressions. I'll read up on emit, but I'm not sure if it'll
fit the need. I'm still guessing precompilation will be the way to go.

[Justin Chase]

True. You're definitely right, now that you mention it. Allowing a user to define inline C# that becomes part of the generation (as spark does) pretty much eliminates the possibility of doing a dynamic method (unless you wrote your own C# parser... which would be foolish). Precompilation would probably solve that though. I believe this is how ASP.NET does it. You change your aspx file and it will generate partial code files for you behind the scenes that become part of your compiled assembly.

[ilog2000]

Unfortunately, I have no practical experience in code generation. So,
just a couple of links on Emit...

3 ways of indirect object instantiation:
http://www.ozcandegirmenci.com/post/2008/02/Create-object-instances-Faster-than-Reflection.aspx

Cloning object with possible populating it with data on the way:
http://whizzodev.blogspot.com/2008/03/object-cloning-using-il-in-c.html

As far as I understand, objects are being created in memory when
generated via Emit


On Aug 21, 10:07 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
wrote:

> No problem. :)
>
> NVelocity has an advantage in that it's parsing templates to an
> in-memory model and rendering from that, so doesn't generate any code
> to compile and load.
>
> The kicker is the engine relies so much on the csharp language for
> template expressions. I'll read up on emit, but I'm not sure if it'll
> fit the need. I'm still guessing precompilation will be the way to go.
>

> >> >http://www.justnbusiness.com-Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -

[Justin Chase]

Well there is no doubt that doing it with emittance would be better than dynamically compiling an assembly with the CodeDom ... but as Louis asserted it's probably not possible with his current scheme. The problem (as I understand it) is with things such as this:

<if condition="x > 10" > ... </ if>

That code that is inside of the condition attribute need to be converted into compilable code... currently it's C#. Spark is using a string builder to create a class that represents your view and it replaces certain parts of the code with what you put inside of these attributes. If you were to go a dynamic method / pure emittance route you'd have to convert the code in that block into IL somehow. How?

The other alternative is to go the NHibernate route where you support a limited set of operators that you parse yourself and translate into your own expression tree. Which is much harder to implement and also much less robust. The spark approach is pretty nice! If he can get that pre-compiled solution down, it should give you the best of both worlds.

Also Louis, if you generated all of the code using the CodeDom instead of a string builder approach and used the custom code segments as CodeSnippetExpressions I think you could completely support arbitrary languages in these expression blocks (though the codedom is a bear to work with!).

[ilog2000]

OK, let me describe the scheme used in NHaml. It might give you some
idea.

1. Declare interface ICompiledView with a single line inside:
string Render();
2. Force the user to give some base class type via ViewBaseType
property of Template compiler:
_templateCompiler.ViewBaseType = typeof(NHamlViewData);
User shall have NHamlViewData in advance and this is a class
containing "variables" for the engine. (Personally I'd prefer to see
here simple class with dictionary mapped to template variables, like
VelocityContext.) There can be another pre-defined class, important
here is only that the type is known to the system.
3. Run type builder (CodeDom) to create a new class derived from base
class and implementing ICompiledView interface
public class Temp_NHamlViewData_ab123e7872e : NHamlViewData,
ICompiledView {...}
4. Instantiate this new class (via Activator in version 1.0, and via
IL generation now).
5. NHaml ends with this, but for my scenario there is still an open
issue, so, another step. NHaml expects NHamlViewData (base class and
data context) self-loaded with data. But for my purposes I need a kind
of properties-filled-at-last-minute. I.e., I need to set some data
after instantiation. And here are 2 ways: (a) NHamlViewData obj =
instance as NHamlViewData; (b) make NHamlViewData just a container

public class NHamlViewData<TViewData> where TViewData : class
{
private TViewData _viewData = null;
public TViewData ViewData
{
get { return _viewData; }
}

public void SetViewData(TViewData viewData)
{
_viewData = viewData;
}
}

6. Finally
string output = instance.Render();
Basically, all the magic is inside Render() implementation. All the
calculations are here. But as I can see, Spark has already have this
part done.

Hope this helps.

P.S. (Disclaimer) I have absolutely no intent to push Spark
development in a particular direction - just feeding your mind :)

> >http://www.ozcandegirmenci.com/post/2008/02/Create-object-instances-F...

> > > >> >http://www.justnbusiness.com-Hidequoted text -

>
> > > >> - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -
>
> --

> Justin Chasehttp://www.justnbusiness.com- Hide quoted text -

[Justin Chase]

This sounds basically like how Spark is doing it, except this phrase you say:

4. Instantiate this new class (via Activator in version 1.0, and via
IL generation now).

That's where all the magic is! How can you generate a class via IL generation using the CodeDom??

[ilog2000]

Justin, the second link from one of my previous posts explains how to
do #4.

And here are the extracts from NHaml which are doing practically the
same:

// TemplateActivator.cs

namespace NHaml
{
public delegate TResult TemplateActivator<TResult>();
}

// ==========================

// TemplateCompiler.cs

// ...
using System.Reflection.Emit;
// ...
namespace NHaml
{
public sealed class TemplateCompiler
{
// ...
private static TemplateActivator<TResult>
CreateFastActivator<TResult>(Type type)
{
var dynamicMethod = new DynamicMethod("activatefast__", type,
null, type);

var ilGenerator = dynamicMethod.GetILGenerator();
var constructor = type.GetConstructor(new Type[] {});

if (constructor == null)
{
return null;
}

ilGenerator.Emit(OpCodes.Newobj, constructor);
ilGenerator.Emit(OpCodes.Ret);

return
(TemplateActivator<TResult>)dynamicMethod.CreateDelegate(typeof(TemplateActivator<TResult>));
}
}
}

That's practically all the magic of dynamic method. Or I misunderstood
you?

What's real magic for me - how to generate that Render() method
implementation!

> > > > > >> >http://www.justnbusiness.com-Hidequotedtext -

>
> > > > > >> - Show quoted text -- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > --

> > > Justin Chasehttp://www.justnbusiness.com-Hide quoted text -

[ilog2000]

As I am not sure what part of generation you meant, here is another
extract from NHaml for CodeDom type creation from source code

public Type Build(string source, string typeName)
{
BuildSource(source);
AddReferences();

var codeProvider = new CSharpCodeProvider(_providerOptions);

_compilerResults = codeProvider
.CompileAssemblyFromSource(_compilerParameters, _source);

if (_compilerResults.Errors.Count == 0)
{
return _compilerResults.CompiledAssembly.GetType(typeName);
}

return null;
}

This type is used for instantiation via dynamic method.

> > > > > >> >http://www.justnbusiness.com-Hidequotedtext -

>
> > > > > >> - Show quoted text -- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > --

> > > Justin Chasehttp://www.justnbusiness.com-Hide quoted text -

[Justin Chase]

Interesting, I thought that compiling an assembly in memory from the CodeDom like that was not allowed in medium trust... What is the benefit of using a dynamic method at this point if you have already generated the assembly can't you just create the type and run the method directly?

Essentially this line:

_compilerResults = codeProvider.CompileAssemblyFromSource(_compilerParameters, _source);

You're taking code and generating an assembly in memory, not taking code and generating a dynamic method. I thought that was not medium trust compatible. Also this was done in a different AppDomain right? I'm pretty sure you can't create AppDomains under medium trust either.

[ilog2000]

Seems, I got everything mixed.

You are right, NHaml makes initial compilation to disk and cache it
(did you mean exactly this when speaking about "precompilation"?) but
do any other instantiation with dynamic method. Frankly speaking, I
tested NHaml and Spark in different shared environments, so, I must re-
test them. I will write here if NHaml has problems on the hosting
where Spark failed.

Another thing to note, that CodeDom allows setting CompilerParameters
GenerateInMemory to true. Can it be a solution? Or this way is
inefficient due to resource consumption and lack of caching?

Sorry for that my mess above.

> > > > > Justin Chasehttp://www.justnbusiness.com-Hidequoted text -

[ilog2000]

To my regret, NHaml also failed on this hosting :(

Let me explain why it's important for me. I am ASP.NET developer and
majority of my web applications are small-to-midsize. I am sick and
tired of WebForms, but stuck to ASP.NET and C#. On the other hand, I
am not happy with hard dependence of MVC (both Castle and MSFT) on
RESTful routing. I feel limited, I need more flexible actions for my
business logic (for example, I often combine different data processing
in one action). Also, plenty of IoC in MVC simply blocks my interest
in digging inside the code. So, I ended with a simple solution of my
own. Now I need a flexible template engine (or several of them). Spark
or NHaml could be a good choice as they allow C# code in template (I
am not an architectural purist). But operation in shared environment
is essential.

> > > > > on- Hide quoted text -
>
> - Show quoted text -...
>
> read more »

[ilog2000]

WOW! Fantastic!

I unexpectedly run into this
http://www.ayende.com/Blog/archive/2007/11/03/RunSharp-Reflection-Emit-for-Mere-Mortals.aspx
and this
http://www.codeproject.com/KB/dotnet/runsharp.aspx

Guys, it worth looking...

> > > > > > > > > >> Yeah... It'd be- Hide quoted text -

[Justin Chase]

I think you're still going to have the same problems with these examples. Things to keep in mind:

• Anything that creates an assembly is not allowed in medium trust.
• Therefore AssemblyBuilder is out
• creating new AppDomains is out
• CodeDomProvider.CompileAssembly* is out
• If you want to allow an inline language there are only two ways to do it:

1. Write your own parser (incredibly hard)
2. Generate a class and stick the inline code into the class. This requires building an assembly, which is not allowed in medium trust. You can pre-compile the assembly in your development environment (where it's full trust) then push this up to the server to get around this issue.

• The only other possible option I can think of would be to build a library that allowed you to take CodeDom objects (such as CodeMemberMethod, CodeStatement and CodeExpression) and transformed this directly into IL using an ILGen from a dynamic method.
  
• For the most part all you want is a single Render method and the data could be passed in as a parameter.
• Generating IL rather than using a string builder to generate C# is incredibly hard to do... but not impossible.
• Yet another option is to take an entirely different approach and to have a non-"tag soup" solution. You could take a XAML like approach where the entire view is a serializable object graph and can interact with custom controls and objects and that is used to render your html. The view would look entirely different but no dynamic compilation would need to be done at all, just deserialization . Imagine asp.net without any inline HTML, all custom controls.
• Here is an example: http://www.justnbusiness.com/Blogs/XAML_View_Engine.aspx
• The only thing about that example is that it's for the CodeDom and wouldn't really solve this problem but you could make an HtmlDom that would be essentially the same.
  

[ilog2000]

Justin, thanks a lot for the explanations. I understand now that the
best I can expect from engines with inline C# to work in medium trust
- precompiled assembly to deploy together with main app library.

As for XAML view engine idea, it's interesting. But upcoming
Silverlight 2 simply kills it - little sense to convert XAML to HTML
if browser can render it "directly".

OK, I feel that I am stealing your time. Thank you again. I will watch
for next Spark releases.

On Aug 23, 6:01 pm, "Justin Chase" <justin.m.ch...@gmail.com> wrote:
> I think you're still going to have the same problems with these examples.

> Things to keep in mind:...
>
> read more »
>
>    - Anything that creates an assembly is not allowed in medium trust.
>       - Therefore AssemblyBuilder is out
>       - creating new AppDomains is out
>       - CodeDomProvider.CompileAssembly* is out
>    - If you want to allow an inline language there are only two ways to do
>    it:
>
>    1. Write your own parser (incredibly hard)
>    2. Generate a class and stick the inline code into the class. This

>    requires building an assembly, which is not allowed in medium trust. You can
>    pre-compile the assembly in your development environment (where it's full
>    trust) then push this up to the server to get around this issue.
>

>    - The only other possible option I can think of would be to build a

>    library that allowed you to take CodeDom objects (such as CodeMemberMethod,
>    CodeStatement and CodeExpression) and transformed this directly into IL
>    using an ILGen from a dynamic method.

>    - For the most part all you want is a single Render method and the data

>       could be passed in as a parameter.

>       - Generating IL rather than using a string builder to generate C# is

>       incredibly hard to do... but not impossible.

>    - Yet another option is to take an entirely different approach and to
>    have a non-"tag soup<http://www.codinghorror.com/blog/archives/001155.html>"

>    solution. You could take a XAML like approach where the entire view is a
>    serializable object graph and can interact with custom controls and objects
>    and that is used to render your html. The view would look entirely different
>    but no dynamic compilation would need to be done at all, just
>    deserialization . Imagine asp.net without any inline HTML, all custom
>    controls.

>       - Here is an example:
>      http://www.justnbusiness.com/Blogs/XAML_View_Engine.aspx
>       - The only thing about that example is that it's for the CodeDom and

>       wouldn't really solve this problem but you could make an HtmlDom
> that would
>       be essentially the same.
>
>
>
> On Sat, Aug 23, 2008 at 9:56 AM, ilog2000 <ilog2...@gmail.com> wrote:
>
> > WOW! Fantastic!
>
> > I unexpectedly run into this
>

> >http://www.ayende.com/Blog/archive/2007/11/03/RunSharp-Reflection-Emi...

> > > > > > > > > the code with what you put- Hide quoted text -