Nick, " All you have to do is create a new AppDomain properly and marshal the call into that app domain." Ah yes, the "properly" part of creating the AppDomain was the root of my issue.
Running code in a different app domain was the easy part, especially since manyobjects we use inherit from MBRO as it is. The part I had trouble with was figuring out what the actual SecurityPermissions needed to be to accurately reproduce a Medium Trust environment in ASP.Net. Due to time, the easier solution was to just write a quick web app to test the changes in. When I looked back at what I was doing, I found that my real problem is that I neglected to use to correct CreateDomain overload (or clear out permissions), so that it inherited the permissions of my test app, which in this case was Full Trust. Had I actually read the MSDN documentation[1], I would have found out that the trust level has code permissions listed in config files on disk. Since you brought up the point of a wrapper, I think that's a better idea than having all these different types directly inheriting from MBRO. But maybe that's just because I'm not a fan of encouraging its use. :) Thanks, Christopher [1] http://msdn.microsoft.com/en-us/library/wyts434y(v=vs.100) On Sat, Aug 18, 2012 at 4:03 PM, Nicholas Paldino [.NET/C# MVP] <casper...@caspershouse.com> wrote: > Chris, > > All you have to do is create a new AppDomain properly and marshal the > call into that app domain. > > You'll need a wrapper that derives from MarshalByRefObject so the > call is marshaled; it's in the marshaled call that you do your test work and > then marshal the results for comparison (or just a Boolean value, it's in the > return value you can serialize things and send them across the app domain > boundary by value). > > See here for greater detail on how to do this: > > http://stackoverflow.com/q/987332/50776 > > - Nick > > -----Original Message----- > From: Christopher Currens [mailto:currens.ch...@gmail.com] > Sent: Tuesday, August 14, 2012 12:16 PM > To: lucene-net-dev@lucene.apache.org > Subject: Re: Lucene.Net 3.0.3 and medium trust > > We should probably try and have unit tests that will spin up medium trust app > domains and run some basic tests in them, so we don't accidentally ship with > something big like this. That is what I initially tried to do to reproduce > this bug on my end, but the code that I would which should have created a > medium trust app domain wasn't working. I had to create an ASP.NET project > and give it medium trust to repro. I'm sure there's a way to do it, though. > > > Thanks, > Christopher > > On Tue, Aug 14, 2012 at 9:08 AM, Christopher Currens > <currens.ch...@gmail.com> wrote: >> Inheriting from WeakReference was the problem. I'm just going to >> remove the wrapper entirely, it doesn't give us any real benefit. The >> code has already been pushed. >> >> >> Thanks, >> Christopher >> >> On Tue, Aug 14, 2012 at 8:46 AM, Prescott Nasser <geobmx...@hotmail.com> >> wrote: >>> It'd be nice to understand where this issue is coming from as it >>> wasn't in 2.9.4 rather than jumping to a quick fix imo. I'll dig a >>> bit myself ~P >>> >>>> Date: Tue, 14 Aug 2012 17:32:29 +0200 >>>> From: si...@devhost.se >>>> To: lucene-net-dev@lucene.apache.org >>>> Subject: Re: Lucene.Net 3.0.3 and medium trust >>>> >>>> Hi, >>>> >>>> It got worse. Building a custom AttributeFactory can only handle a >>>> few cases, I needed to subclass _every_ TokenStream/TokenFilter to >>>> override all attribute-handling methods (AddAttribute, GetAttribute, >>>> etc), and all analyzers to use these streams, to use a dictionary >>>> with strong references just for medium trust... I gave up before >>>> doing that. ;) >>>> >>>> Is there any use cases where we need to garbage collect attributes >>>> before the stream/attribute source is closed? Changing to a normal >>>> dictionary seems like a quick fix. >>>> >>>> // Simon >>>> >>>> >>>> On 2012-08-14 17:21, Christopher Currens wrote: >>>> > It must be something we've missed, as we want to target medium >>>> > trust locations in the future. I can't think of anything off the >>>> > top of my head that would require medium trust, though, let alone >>>> > unmanaged code. I'll dive into this. >>>> > >>>> > >>>> > Thanks, >>>> > Christopher >>>> > >>>> > On Mon, Aug 13, 2012 at 10:01 PM, Simon Svensson <si...@devhost.se> >>>> > wrote: >>>> >> Hi, >>>> >> >>>> >> I'm having trouble upgrading a web application running under >>>> >> medium trust from 2.9.4 to 3.0.3. Code that previously worked now >>>> >> throws a SecurityException. >>>> >> >>>> >> [SecurityException: Request for the permission of type >>>> >> 'System.Security.Permissions.SecurityPermission, mscorlib, >>>> >> Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' >>>> >> failed.] >>>> >> Lucene.Net.Support.WeakKey`1..ctor(T key) +0 >>>> >> Lucene.Net.Support.WeakDictionary`2.get_Item(TKey key) +113 >>>> >> Lucene.Net.Util.DefaultAttributeFactory.GetClassForInterface() +178 >>>> >> Lucene.Net.Util.DefaultAttributeFactory.CreateAttributeInstance() >>>> >> +95 >>>> >> Lucene.Net.Util.AttributeSource.AddAttribute() +375 >>>> >> Lucene.Net.Analysis.CharTokenizer..ctor(TextReader input) +126 >>>> >> Lucene.Net.Analysis.WhitespaceTokenizer..ctor(TextReader in) >>>> >> +37 >>>> >> >>>> >> >>>> >> The DefaultAttributeFactory, via WeakReference, requires >>>> >> SecurityPermissionFlag.UnmanagedCode which is not present under >>>> >> medium trust. There's an >>>> >> AttributeFactory.DEFAULT_ATTRIBUTE_FACTORY which I could to >>>> >> replace the DefaultAttributeFactory, but it's readonly. I'm >>>> >> rewriting my code to call the constructor overload (on >>>> >> tokenizers) accepting an AttributeFactory, but this means that I cannot >>>> >> use any existing Analyzer since they don't provide an extension points >>>> >> to change the AttributeFactory. >>>> >> >>>> >> Is medium trust [using default classes] dropped in 3.0.3, or is >>>> >> this something we've missed? >>>> >> >>>> >> // Simon >>>> >>> > >
