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