Thanks Dino - will try it out when I get a chance.

Davy

On Tue, Apr 7, 2009 at 3:33 AM, Dino Viehland <di...@microsoft.com> wrote:
> Ahh, I see, you want to add something like:
>
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ());
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ());
>    gen.Emit(OpCodes.Newobj, clr.GetClrType(System.Uri).GetConstructor( (str, 
> ) ));
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ());
>    gen.Emit(OpCodes.Newobj, 
> clr.GetClrType(System.IO.FileInfo).GetConstructor( (str, ) ))
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(System.IO.FileInfo).GetMethod("get_Directory"), ())
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ())
>    gen.EmitCall(OpCodes.Call, 
> clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), ())
>
> right before we get the ScriptCode assembly in GenerateExe.
>
> It's really unfortunate that this is necessary.  In theory we can burn a 
> reference from your DLL into your EXE and have the CLR load the assembly and 
> it should be able to pick it up w/o changing the CWD.  The problem seems to 
> be that we end up with "DIE.EXE" and "DIE.DLL" and it would appear the CLR 
> always loads DIE.EXE and then it doesn't find the types in DIE.DLL.  
> Presumably if we named them different this would work.  Maybe we should 
> enable naming them differently or maybe we should enable generating just one 
> EXE instead of the wrapper EXE.
>
> Feel free to open a feature request - at the very least we can make an option 
> to insert the above code :)
>
>> -----Original Message-----
>> From: users-boun...@lists.ironpython.com [mailto:users-
>> boun...@lists.ironpython.com] On Behalf Of Davy Mitchell
>> Sent: Monday, April 06, 2009 10:57 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Modifying The PYC Stub EXE
>>
>> Hi Dino,
>>
>> All the DLLs are in the Build directory. Everything runs great if the
>> CWD is the folder containing
>> the EXE. If you try and run it from another folder things go wrong
>> (File Not Found Exception).
>>
>> I've posted a basic repro on my Skydrive
>> http://cid-
>> 1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip
>>
>> cd hello\build\ and die.exe will run
>> cd hello and run .\build\die.exe and it will fail
>>
>> Thanks,
>> Davy Mitchell
>>
>> On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland <di...@microsoft.com>
>> wrote:
>> > What DLLs you want to be loaded?  The reason I ask is that .NET
>> assembly
>> > loading doesn't really work on the basis of the current working
>> directory -
>> > instead it looks at the app base which by default is where your EXE
>> is
>> > located.  We do modify sys.path so that IronPython can load things
>> outside
>> > of the app base but I wouldn't suggest pushing this too far.  Instead
>> I'd
>> > propose doing what a normal build process does and copy the DLLs into
>> the
>> > build directory.
>> >
>> >
>> >
>> > From: users-boun...@lists.ironpython.com
>> > [mailto:users-boun...@lists.ironpython.com] On Behalf Of Davy
>> Mitchell
>> > Sent: Sunday, April 05, 2009 3:55 AM
>> > To: Discussion of IronPython
>> > Subject: [IronPython] Modifying The PYC Stub EXE
>> >
>> >
>> >
>> > Hi Folks,
>> >
>> >
>> >
>> > I am looking to modify the EXE stub generated by PYC so that it will
>> set the
>> > current working directory to the location of the EXE
>> >
>> > before loading its assemblies.
>> >
>> >
>> >
>> > The problem I am having is I build my EXE to a sub-folder called
>> BUILD. If I
>> > call it in the form .\build\die.exe then it can't find the DLLs.
>> >
>> > This can be worked around with shortcuts setting the working dir etc
>> but
>> > having this option in code in PYC would be useful.
>> >
>> >
>> >
>> > Forgive me if I am very very muddled up about something :-)
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Davy Mitchell
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users@lists.ironpython.com
>> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> >
>> >
>> _______________________________________________
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to