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
