Re: [IronPython] Problem with Creating Executable using SharpDevelop
> On Jul 17, 10:07 am, Bruce Bromberek > > Make sure the Target machine has been upgraded to .Net 3.5 SP1. Don't take > > any flack - make them upgrade.* This fixed the problem. Works on both XP and Vista. Thanks again Bruce! ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Jul 17, 10:07 am, Bruce Bromberek wrote: > Look at your references to the 5 ironpython DLLs. Decide right now: Are > you going to use the ones that ship with SharpDevelop or the ones using that > come with IronPython. Choose one and be consistent. > > I'm still working though how to Build a WIX installer project , so I > currently ZIP up the release folder generated by SharpDevelop and make sure > everything is there. Here's an example for a simple program I have > distributed to coworkers. > Make sure the Target machine has been upgraded to .Net 3.5 SP1. Don't take > any flack - make them upgrade.* > > *Make sure they are not running on a network share. Weird things with trust > can happen with shares. See my recent cry for help on this list for more > info.* > Bruce, thanks a lot for sharing your experience. I'll try your suggestions. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Jul 10, 6:46 pm, Curt Hagenlocher wrote: > It would probably be more immediately useful if you were to provide > the specific error message and a listing of the directory from which > you're trying to run the program. Given that it works on at least one > machine, it's likely to be context-related rather than code-related. > Thanks Curt. I'll run the program again and get back to you on this. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Kelie- I just went through this process recently myself. My rules of thumb are as follows: *When building the App:* Look at your references to the 5 ironpython DLLs. Decide right now: Are you going to use the ones that ship with SharpDevelop or the ones using that come with IronPython. Choose one and be consistent. I'm still working though how to Build a WIX installer project , so I currently ZIP up the release folder generated by SharpDevelop and make sure everything is there. Here's an example for a simple program I have distributed to coworkers. AIIMTool.dll AIIMTool.exe ICSharpCode.SharpZipLib.dll IronMath.dll IronPython.dll IronPython.Modules.dll IronPythonTest.dll Microsoft.Scripting.Core.dll Microsoft.Scripting.dll Microsoft.Scripting.ExtensionAttribute.dll * Make sure the Target machine has been upgraded to .Net 3.5 SP1. Don't take any flack - make them upgrade.* *Make sure they are not running on a network share. Weird things with trust can happen with shares. See my recent cry for help on this list for more info.* -Bruce On Fri, Jul 10, 2009 at 1:34 AM, Kelie wrote: > Hello, > > I created a simple program with a few buttons, checkboxes, textboxes, > etc. and it worked fine. The form was created in the latest > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > solution. In the release folder there were these files: > > IronPython.dll > ManningsSolver.dll > ManningsSolver.exe > Microsoft.Scripting.Core.dll > Microsoft.Scripting.dll > Microsoft.Scripting.ExtensionAttribute.dll > > When tried on two computers with IronPython installed and with the > source code files, the program worked. But it failed on another > computer that does not have these. And error message was very > generic .NET error. I don't exactly remember what it was. Is this > normal? > > Btw, since I have SharpDevelop installed, do I have to install > IronPython in order to write programs in IronPython? Or does it matter > which version of IronPython I install. The answer seems to be "No" > because I see those .dll files for IronPython in this folder "C: > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > \PythonBinding" which are dated Feb 2009. Guess they're not the > latest. > > Thanks, > > Kelie > > ___ > 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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
We've kept assembly version numbers the same for 2.0.x (and change the assembly file version for each patch release) so that hosted IronPython applications do not need to be rebuilt for each release. This approach is great as it ensures binary compatibility for compiled applications built on top of IronPython but it also has one major disadvantage: we have to be incredibly conservative in terms of bug fixing for patch releases. This means zero changes to any method signature whether it's in the DLR or IronPython. Also, we outright reject a number of bug fixes for patch releases based on their complexity alone which might cause instability in other areas. Our current 2.6.x planning entails not only fixing a lot of "hard" bugs where the fixes themselves might cause new instability, but also far more bugs than any prior IronPython release series. As such, we need the flexibility to change method signatures (without injecting public API incompatibilities in areas like hosting of course) between patch releases. The safest way to do this for those building compiled applications with IronPython is to rev assembly version numbers for each release of 2.6. Finally, please recall that earlier I said we "strongly suspect" we'll be using different assembly version numbers for 2.6. This isn't set in stone yet:) If you feel strongly on this one way or another, please let us know as this will influence the final decision. Thanks, Dave From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Simon Dahlbacka Sent: Tuesday, July 14, 2009 5:56 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop On Mon, Jul 13, 2009 at 7:26 PM, Dave Fugate mailto:dfug...@microsoft.com>> wrote: On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc... Can't you update AssemblyFileVersion and leave AssemblyVersion or is there a problem with that too? -Original Message- From: users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>] On Behalf Of Michael Foord Sent: Monday, July 13, 2009 4:00 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop Jeff Hardy wrote: > On Fri, Jul 10, 2009 at 12:50 PM, Michael > Foordmailto:fuzzy...@voidspace.org.uk>> wrote: > >> Are there issues around assembly versions and the GAC? I'm thinking >> particularly of where newer versions of IronPython are released as drop-in >> replacements so the version numbers are not updated. If a previous version >> is in the GAC isn't there a likelihood that an application that ships with a >> newer version will still load the GAC'd older version... ? >> >> My *impression* was that adding stuff to the GAC was a recipe for DLL hell >> and therefore it was better left to individual users rather than being >> automatic on installation. This opinion may be ill-informed however... >> > > You just have to be *really* careful with you assembly versions, and > what kinds of changes cause a rev of version numbers. However, I don't > think it should be the default, but it would be nice to have the > option during installation. I think gacutil is only included in the > SDK anyway. > > Right. I think the issue of version numbering is tricky, which is why I'm nervous about IronPython being GAC'd. As an example, the IronPython 2.0.1 and 2.0 assemblies have the same version numbers - and I understand why and don't disagree with this decision - but the net result is that Resolver One required 2.0.1 and would probably fail if the user has 2.0 in the GAC. I certainly wouldn't object to it being an installer option, but it would still make me nervous... :-) Having minor IronPython versions have new assembly versions would probably help - but with the disadvantage that they are no longer drop-in replacements. Michael > - Jeff > ___ > Users mailing list > Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com<mailto: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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Mon, Jul 13, 2009 at 7:26 PM, Dave Fugate wrote: > On a related note, I strongly suspect we'll be using different assembly > version numbers for IronPython 2.6.0/2.6.1/etc... > > Can't you update AssemblyFileVersion and leave AssemblyVersion or is there a problem with that too? > > -Original Message- > From: users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, July 13, 2009 4:00 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Problem with Creating Executable using > SharpDevelop > > Jeff Hardy wrote: > > On Fri, Jul 10, 2009 at 12:50 PM, Michael > > Foord wrote: > > > >> Are there issues around assembly versions and the GAC? I'm thinking > >> particularly of where newer versions of IronPython are released as > drop-in > >> replacements so the version numbers are not updated. If a previous > version > >> is in the GAC isn't there a likelihood that an application that ships > with a > >> newer version will still load the GAC'd older version... ? > >> > >> My *impression* was that adding stuff to the GAC was a recipe for DLL > hell > >> and therefore it was better left to individual users rather than being > >> automatic on installation. This opinion may be ill-informed however... > >> > > > > You just have to be *really* careful with you assembly versions, and > > what kinds of changes cause a rev of version numbers. However, I don't > > think it should be the default, but it would be nice to have the > > option during installation. I think gacutil is only included in the > > SDK anyway. > > > > > > Right. I think the issue of version numbering is tricky, which is why > I'm nervous about IronPython being GAC'd. > > As an example, the IronPython 2.0.1 and 2.0 assemblies have the same > version numbers - and I understand why and don't disagree with this > decision - but the net result is that Resolver One required 2.0.1 and > would probably fail if the user has 2.0 in the GAC. > > I certainly wouldn't object to it being an installer option, but it > would still make me nervous... :-) > > Having minor IronPython versions have new assembly versions would > probably help - but with the disadvantage that they are no longer > drop-in replacements. > > > Michael > > > - Jeff > > ___ > > Users mailing list > > Users@lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > ___ > 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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Mon, Jul 13, 2009 at 10:26 AM, Dave Fugate wrote: > On a related note, I strongly suspect we'll be using different assembly > version numbers for IronPython 2.6.0/2.6.1/etc... I'd prefer not to have to respin NWSGI for every minor version of IronPython. I know about assemblyBinding, and I can make it work, but it hurts the user experience having to know exactly what version of IronPython is installed. This isn't the case for CPython, where extensions target the 2.6 version only, no 2.6.2. I see it as similar to the .NET FX service packs - the assembly versions remain the same, even though there are changes to the assembly, and it seems to work out (mostly, anyway). Does anyone know if there's a way, in a .config file, to tell .NET to use a local copy instead of the GAC? Some combination of assemblyBinding elemnts should do it, but I'm unable to try right now. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc... Dave -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, July 13, 2009 4:00 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop Jeff Hardy wrote: > On Fri, Jul 10, 2009 at 12:50 PM, Michael > Foord wrote: > >> Are there issues around assembly versions and the GAC? I'm thinking >> particularly of where newer versions of IronPython are released as drop-in >> replacements so the version numbers are not updated. If a previous version >> is in the GAC isn't there a likelihood that an application that ships with a >> newer version will still load the GAC'd older version... ? >> >> My *impression* was that adding stuff to the GAC was a recipe for DLL hell >> and therefore it was better left to individual users rather than being >> automatic on installation. This opinion may be ill-informed however... >> > > You just have to be *really* careful with you assembly versions, and > what kinds of changes cause a rev of version numbers. However, I don't > think it should be the default, but it would be nice to have the > option during installation. I think gacutil is only included in the > SDK anyway. > > Right. I think the issue of version numbering is tricky, which is why I'm nervous about IronPython being GAC'd. As an example, the IronPython 2.0.1 and 2.0 assemblies have the same version numbers - and I understand why and don't disagree with this decision - but the net result is that Resolver One required 2.0.1 and would probably fail if the user has 2.0 in the GAC. I certainly wouldn't object to it being an installer option, but it would still make me nervous... :-) Having minor IronPython versions have new assembly versions would probably help - but with the disadvantage that they are no longer drop-in replacements. Michael > - Jeff > ___ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Jeff Hardy wrote: On Fri, Jul 10, 2009 at 12:50 PM, Michael Foord wrote: Are there issues around assembly versions and the GAC? I'm thinking particularly of where newer versions of IronPython are released as drop-in replacements so the version numbers are not updated. If a previous version is in the GAC isn't there a likelihood that an application that ships with a newer version will still load the GAC'd older version... ? My *impression* was that adding stuff to the GAC was a recipe for DLL hell and therefore it was better left to individual users rather than being automatic on installation. This opinion may be ill-informed however... You just have to be *really* careful with you assembly versions, and what kinds of changes cause a rev of version numbers. However, I don't think it should be the default, but it would be nice to have the option during installation. I think gacutil is only included in the SDK anyway. Right. I think the issue of version numbering is tricky, which is why I'm nervous about IronPython being GAC'd. As an example, the IronPython 2.0.1 and 2.0 assemblies have the same version numbers - and I understand why and don't disagree with this decision - but the net result is that Resolver One required 2.0.1 and would probably fail if the user has 2.0 in the GAC. I certainly wouldn't object to it being an installer option, but it would still make me nervous... :-) Having minor IronPython versions have new assembly versions would probably help - but with the disadvantage that they are no longer drop-in replacements. Michael - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Fri, Jul 10, 2009 at 12:50 PM, Michael Foord wrote: > Are there issues around assembly versions and the GAC? I'm thinking > particularly of where newer versions of IronPython are released as drop-in > replacements so the version numbers are not updated. If a previous version > is in the GAC isn't there a likelihood that an application that ships with a > newer version will still load the GAC'd older version... ? > > My *impression* was that adding stuff to the GAC was a recipe for DLL hell > and therefore it was better left to individual users rather than being > automatic on installation. This opinion may be ill-informed however... You just have to be *really* careful with you assembly versions, and what kinds of changes cause a rev of version numbers. However, I don't think it should be the default, but it would be nice to have the option during installation. I think gacutil is only included in the SDK anyway. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Fri, Jul 10, 2009 at 9:36 PM, Kelie wrote: > > Btw, is there a way to post attachment to this mailing list? The > program I created is quite simple. Some of you might be able to spot > the problem if you see the code. Thanks again. It would probably be more immediately useful if you were to provide the specific error message and a listing of the directory from which you're trying to run the program. Given that it works on at least one machine, it's likely to be context-related rather than code-related. -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Jul 10, 6:03 am, Dino Viehland wrote: > In general you need IronPython to be present to run IronPython apps - even > if they're compiled. And IronPython will need to be next to the app > unless IronPython has been installed into the GAC (which we do not > do by default). Also you probably want to include IronPython.Modules.dll > as well in addition to the DLLs you have here. I imagine at some point > in the future we could add some sort of tree shaking compiler support > that links in IronPython w/ the app but we're a ways off from making > that a priority. > > The SharpDevelop specific question I'm less sure about. I installed IronPython 2.01 (the same version that I have on my two computers) on the other computer and it still didn't work. Anything else I should try? Btw, is there a way to post attachment to this mailing list? The program I created is quite simple. Some of you might be able to spot the problem if you see the code. Thanks again. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Are there issues around assembly versions and the GAC? I'm thinking particularly of where newer versions of IronPython are released as drop-in replacements so the version numbers are not updated. If a previous version is in the GAC isn't there a likelihood that an application that ships with a newer version will still load the GAC'd older version... ? My *impression* was that adding stuff to the GAC was a recipe for DLL hell and therefore it was better left to individual users rather than being automatic on installation. This opinion may be ill-informed however... Michael Dino Viehland wrote: The big problem w/ installing into the GAC from our perspective is that assemblies in the GAC are fully trusted and can be loaded by anyone. Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to our assemblies and you potentially have a recipe for disaster. In theory we believe this is ok because we’re also SecurityTransparent but we haven’t had the deeper conversion w/ the CLR team about combining all 3 of these so we continue to be conservative and not install into the GAC. We should probably look into removing APTCA though – the reason why we applied it in the 1.x time frame was due to a performance problem w/ signed non-APTCA assemblies which may now be fixed in the CLR. As for actually doing the installation you now need to invoke gacutil 5 times – once for each DLL. IronPython, IronPython.Modules, Microsoft.Scripting, Microsoft.Scripting.Core, and Microsoft.Scripting.ExtensionAttribute. In 2.6 there’ll be one more assembly to add to the list – Microsoft.Scripting.Debugging. *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Jonathan March *Sent:* Friday, July 10, 2009 9:28 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Problem with Creating Executable using SharpDevelop Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".) For us .net ignorami: * What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app? * Is installing into GAC still done by invoking gacutil twice as described here:? http://www.manifold.net/doc/scripts.htm Thanks. On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <mailto:di...@microsoft.com>> wrote: In general you need IronPython to be present to run IronPython apps - even if they're compiled. And IronPython will need to be next to the app unless IronPython has been installed into the GAC (which we do not do by default). Also you probably want to include IronPython.Modules.dll as well in addition to the DLLs you have here. I imagine at some point in the future we could add some sort of tree shaking compiler support that links in IronPython w/ the app but we're a ways off from making that a priority. The SharpDevelop specific question I'm less sure about. > -Original Message- > From: users-boun...@lists.ironpython.com <mailto:users-boun...@lists.ironpython.com> [mailto:users- <mailto:users-> > boun...@lists.ironpython.com <mailto:boun...@lists.ironpython.com>] On Behalf Of Kelie > Sent: Thursday, July 09, 2009 11:34 PM > To: users@lists.ironpython.com <mailto:users@lists.ironpython.com> > Subject: [IronPython] Problem with Creating Executable using > SharpDevelop > > Hello, > > I created a simple program with a few buttons, checkboxes, textboxes, > etc. and it worked fine. The form was created in the latest > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > solution. In the release folder there were these files: > > IronPython.dll > ManningsSolver.dll > ManningsSolver.exe > Microsoft.Scripting.Core.dll > Microsoft.Scripting.dll > Microsoft.Scripting.ExtensionAttribute.dll > > When tried on two computers with IronPython installed and with the > source code files, the program worked. But it failed on another > computer that does not have these. And error message was very > generic .NET error. I don't exactly remember what it was. Is this > normal? > > Btw, since I have SharpDevelop installed, do I have to install > IronPython in order to write programs in IronPython? Or does it matter > which version of IronPython I install. The answer seems to be "No" > because I see those .dll files for IronPython in this folder "C: > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > \PythonBinding" which are dated Feb 2009. Guess they're not the > latest. > > Thanks, > > Kelie > > ___ > Users mailing list > Users@lists.ironpyth
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Thanks for the quick response and forward motion! On Fri, Jul 10, 2009 at 12:42 PM, Dino Viehland wrote: > Ok, I just confirmed that mixing APTCA + SecurityTransparent + GAC works > as expected so putting ourselves in the GAC should be perfectly fine to do. > There may be some additional internal process hurdles for us to jump over > but we can look into that. > > > > *From:* users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *On Behalf Of *Dino Viehland > *Sent:* Friday, July 10, 2009 9:45 AM > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Problem with Creating Executable using > SharpDevelop > > > > The big problem w/ installing into the GAC from our perspective is that > assemblies in the GAC are fully trusted and can be loaded by anyone. > Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to > our assemblies and you potentially have a recipe for disaster. In theory we > believe this is ok because we’re also SecurityTransparent but we haven’t had > the deeper conversion w/ the CLR team about combining all 3 of these so we > continue to be conservative and not install into the GAC. > > > > We should probably look into removing APTCA though – the reason why we > applied it in the 1.x time frame was due to a performance problem w/ signed > non-APTCA assemblies which may now be fixed in the CLR. > > > > As for actually doing the installation you now need to invoke gacutil 5 > times – once for each DLL. IronPython, IronPython.Modules, > Microsoft.Scripting, Microsoft.Scripting.Core, and > Microsoft.Scripting.ExtensionAttribute. In 2.6 there’ll be one more > assembly to add to the list – Microsoft.Scripting.Debugging. > > > > *From:* users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *On Behalf Of *Jonathan March > *Sent:* Friday, July 10, 2009 9:28 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Problem with Creating Executable using > SharpDevelop > > > > Installing IP into the GAC is something apparently not much discussed in > polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".) > > For us .net ignorami: > * What is the downside to installing IP into the GAC? Is it that different > apps will be dependent on different IP versions so better just to keep the > IP DLLs together with each app? > * Is installing into GAC still done by invoking gacutil twice as described > here:? > http://www.manifold.net/doc/scripts.htm > > Thanks. > > On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland > wrote: > > In general you need IronPython to be present to run IronPython apps - even > if they're compiled. And IronPython will need to be next to the app > unless IronPython has been installed into the GAC (which we do not > do by default). Also you probably want to include IronPython.Modules.dll > as well in addition to the DLLs you have here. I imagine at some point > in the future we could add some sort of tree shaking compiler support > that links in IronPython w/ the app but we're a ways off from making > that a priority. > > The SharpDevelop specific question I'm less sure about. > > > > -----Original Message----- > > From: users-boun...@lists.ironpython.com [mailto:users- > > boun...@lists.ironpython.com] On Behalf Of Kelie > > Sent: Thursday, July 09, 2009 11:34 PM > > To: users@lists.ironpython.com > > Subject: [IronPython] Problem with Creating Executable using > > SharpDevelop > > > > Hello, > > > > I created a simple program with a few buttons, checkboxes, textboxes, > > etc. and it worked fine. The form was created in the latest > > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > > solution. In the release folder there were these files: > > > > IronPython.dll > > ManningsSolver.dll > > ManningsSolver.exe > > Microsoft.Scripting.Core.dll > > Microsoft.Scripting.dll > > Microsoft.Scripting.ExtensionAttribute.dll > > > > When tried on two computers with IronPython installed and with the > > source code files, the program worked. But it failed on another > > computer that does not have these. And error message was very > > generic .NET error. I don't exactly remember what it was. Is this > > normal? > > > > Btw, since I have SharpDevelop installed, do I have to install > > IronPython in order to write programs in IronPython? Or does it matter > > which version of IronPython I install. The answer seems to be "No" > > because I see those .dll files for IronPython in
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Ok, I just confirmed that mixing APTCA + SecurityTransparent + GAC works as expected so putting ourselves in the GAC should be perfectly fine to do. There may be some additional internal process hurdles for us to jump over but we can look into that. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, July 10, 2009 9:45 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop The big problem w/ installing into the GAC from our perspective is that assemblies in the GAC are fully trusted and can be loaded by anyone. Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to our assemblies and you potentially have a recipe for disaster. In theory we believe this is ok because we're also SecurityTransparent but we haven't had the deeper conversion w/ the CLR team about combining all 3 of these so we continue to be conservative and not install into the GAC. We should probably look into removing APTCA though - the reason why we applied it in the 1.x time frame was due to a performance problem w/ signed non-APTCA assemblies which may now be fixed in the CLR. As for actually doing the installation you now need to invoke gacutil 5 times - once for each DLL. IronPython, IronPython.Modules, Microsoft.Scripting, Microsoft.Scripting.Core, and Microsoft.Scripting.ExtensionAttribute. In 2.6 there'll be one more assembly to add to the list - Microsoft.Scripting.Debugging. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jonathan March Sent: Friday, July 10, 2009 9:28 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".) For us .net ignorami: * What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app? * Is installing into GAC still done by invoking gacutil twice as described here:? http://www.manifold.net/doc/scripts.htm Thanks. On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland mailto:di...@microsoft.com>> wrote: In general you need IronPython to be present to run IronPython apps - even if they're compiled. And IronPython will need to be next to the app unless IronPython has been installed into the GAC (which we do not do by default). Also you probably want to include IronPython.Modules.dll as well in addition to the DLLs you have here. I imagine at some point in the future we could add some sort of tree shaking compiler support that links in IronPython w/ the app but we're a ways off from making that a priority. The SharpDevelop specific question I'm less sure about. > -Original Message- > From: > users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> > [mailto:users-<mailto:users-> > boun...@lists.ironpython.com<mailto:boun...@lists.ironpython.com>] On Behalf > Of Kelie > Sent: Thursday, July 09, 2009 11:34 PM > To: users@lists.ironpython.com<mailto:users@lists.ironpython.com> > Subject: [IronPython] Problem with Creating Executable using > SharpDevelop > > Hello, > > I created a simple program with a few buttons, checkboxes, textboxes, > etc. and it worked fine. The form was created in the latest > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > solution. In the release folder there were these files: > > IronPython.dll > ManningsSolver.dll > ManningsSolver.exe > Microsoft.Scripting.Core.dll > Microsoft.Scripting.dll > Microsoft.Scripting.ExtensionAttribute.dll > > When tried on two computers with IronPython installed and with the > source code files, the program worked. But it failed on another > computer that does not have these. And error message was very > generic .NET error. I don't exactly remember what it was. Is this > normal? > > Btw, since I have SharpDevelop installed, do I have to install > IronPython in order to write programs in IronPython? Or does it matter > which version of IronPython I install. The answer seems to be "No" > because I see those .dll files for IronPython in this folder "C: > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > \PythonBinding" which are dated Feb 2009. Guess they're not the > latest. > > Thanks, > > Kelie > > ___ > Users mailing list > Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Jeff wrote: > > For the sake of simplifying the NWSGI usage instructions (or: think of > the children!), please reconsider :). > Ok, we don't seem to have a issue on CodePlex for this so I've created one: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23450 Feel free to vote on it - I doubt we'd do it for 2.6 but who knows... ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Jeff wrote: > > How would this affect partially-trusted applications? IIRC any > assemblies they reference must have APTCA. This is quite important for > web applications as they are often hosted in medium trust. > Good point. If we confirm that APTCA, SecurityTransparent and GAC all mix perfectly fine then we could just leave APTCA. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
On Fri, Jul 10, 2009 at 10:44 AM, Dino Viehland wrote: > The big problem w/ installing into the GAC from our perspective is that > assemblies in the GAC are fully trusted and can be loaded by anyone. > Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to > our assemblies and you potentially have a recipe for disaster. In theory we > believe this is ok because we’re also SecurityTransparent but we haven’t had > the deeper conversion w/ the CLR team about combining all 3 of these so we > continue to be conservative and not install into the GAC. For the sake of simplifying the NWSGI usage instructions (or: think of the children!), please reconsider :). > > We should probably look into removing APTCA though – the reason why we > applied it in the 1.x time frame was due to a performance problem w/ signed > non-APTCA assemblies which may now be fixed in the CLR. How would this affect partially-trusted applications? IIRC any assemblies they reference must have APTCA. This is quite important for web applications as they are often hosted in medium trust. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Problem with Creating Executable using SharpDevelop
The big problem w/ installing into the GAC from our perspective is that assemblies in the GAC are fully trusted and can be loaded by anyone. Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to our assemblies and you potentially have a recipe for disaster. In theory we believe this is ok because we're also SecurityTransparent but we haven't had the deeper conversion w/ the CLR team about combining all 3 of these so we continue to be conservative and not install into the GAC. We should probably look into removing APTCA though - the reason why we applied it in the 1.x time frame was due to a performance problem w/ signed non-APTCA assemblies which may now be fixed in the CLR. As for actually doing the installation you now need to invoke gacutil 5 times - once for each DLL. IronPython, IronPython.Modules, Microsoft.Scripting, Microsoft.Scripting.Core, and Microsoft.Scripting.ExtensionAttribute. In 2.6 there'll be one more assembly to add to the list - Microsoft.Scripting.Debugging. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jonathan March Sent: Friday, July 10, 2009 9:28 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".) For us .net ignorami: * What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app? * Is installing into GAC still done by invoking gacutil twice as described here:? http://www.manifold.net/doc/scripts.htm Thanks. On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland mailto:di...@microsoft.com>> wrote: In general you need IronPython to be present to run IronPython apps - even if they're compiled. And IronPython will need to be next to the app unless IronPython has been installed into the GAC (which we do not do by default). Also you probably want to include IronPython.Modules.dll as well in addition to the DLLs you have here. I imagine at some point in the future we could add some sort of tree shaking compiler support that links in IronPython w/ the app but we're a ways off from making that a priority. The SharpDevelop specific question I'm less sure about. > -Original Message- > From: > users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> > [mailto:users-<mailto:users-> > boun...@lists.ironpython.com<mailto:boun...@lists.ironpython.com>] On Behalf > Of Kelie > Sent: Thursday, July 09, 2009 11:34 PM > To: users@lists.ironpython.com<mailto:users@lists.ironpython.com> > Subject: [IronPython] Problem with Creating Executable using > SharpDevelop > > Hello, > > I created a simple program with a few buttons, checkboxes, textboxes, > etc. and it worked fine. The form was created in the latest > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > solution. In the release folder there were these files: > > IronPython.dll > ManningsSolver.dll > ManningsSolver.exe > Microsoft.Scripting.Core.dll > Microsoft.Scripting.dll > Microsoft.Scripting.ExtensionAttribute.dll > > When tried on two computers with IronPython installed and with the > source code files, the program worked. But it failed on another > computer that does not have these. And error message was very > generic .NET error. I don't exactly remember what it was. Is this > normal? > > Btw, since I have SharpDevelop installed, do I have to install > IronPython in order to write programs in IronPython? Or does it matter > which version of IronPython I install. The answer seems to be "No" > because I see those .dll files for IronPython in this folder "C: > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > \PythonBinding" which are dated Feb 2009. Guess they're not the > latest. > > Thanks, > > Kelie > > ___ > Users mailing list > Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com<mailto: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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".) For us .net ignorami: * What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app? * Is installing into GAC still done by invoking gacutil twice as described here:? http://www.manifold.net/doc/scripts.htm Thanks. On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland wrote: > In general you need IronPython to be present to run IronPython apps - even > if they're compiled. And IronPython will need to be next to the app > unless IronPython has been installed into the GAC (which we do not > do by default). Also you probably want to include IronPython.Modules.dll > as well in addition to the DLLs you have here. I imagine at some point > in the future we could add some sort of tree shaking compiler support > that links in IronPython w/ the app but we're a ways off from making > that a priority. > > The SharpDevelop specific question I'm less sure about. > > > -Original Message- > > From: users-boun...@lists.ironpython.com [mailto:users- > > boun...@lists.ironpython.com] On Behalf Of Kelie > > Sent: Thursday, July 09, 2009 11:34 PM > > To: users@lists.ironpython.com > > Subject: [IronPython] Problem with Creating Executable using > > SharpDevelop > > > > Hello, > > > > I created a simple program with a few buttons, checkboxes, textboxes, > > etc. and it worked fine. The form was created in the latest > > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > > solution. In the release folder there were these files: > > > > IronPython.dll > > ManningsSolver.dll > > ManningsSolver.exe > > Microsoft.Scripting.Core.dll > > Microsoft.Scripting.dll > > Microsoft.Scripting.ExtensionAttribute.dll > > > > When tried on two computers with IronPython installed and with the > > source code files, the program worked. But it failed on another > > computer that does not have these. And error message was very > > generic .NET error. I don't exactly remember what it was. Is this > > normal? > > > > Btw, since I have SharpDevelop installed, do I have to install > > IronPython in order to write programs in IronPython? Or does it matter > > which version of IronPython I install. The answer seems to be "No" > > because I see those .dll files for IronPython in this folder "C: > > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > > \PythonBinding" which are dated Feb 2009. Guess they're not the > > latest. > > > > Thanks, > > > > Kelie > > > > ___ > > 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
Re: [IronPython] Problem with Creating Executable using SharpDevelop
In general you need IronPython to be present to run IronPython apps - even if they're compiled. And IronPython will need to be next to the app unless IronPython has been installed into the GAC (which we do not do by default). Also you probably want to include IronPython.Modules.dll as well in addition to the DLLs you have here. I imagine at some point in the future we could add some sort of tree shaking compiler support that links in IronPython w/ the app but we're a ways off from making that a priority. The SharpDevelop specific question I'm less sure about. > -Original Message- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Kelie > Sent: Thursday, July 09, 2009 11:34 PM > To: users@lists.ironpython.com > Subject: [IronPython] Problem with Creating Executable using > SharpDevelop > > Hello, > > I created a simple program with a few buttons, checkboxes, textboxes, > etc. and it worked fine. The form was created in the latest > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the > solution. In the release folder there were these files: > > IronPython.dll > ManningsSolver.dll > ManningsSolver.exe > Microsoft.Scripting.Core.dll > Microsoft.Scripting.dll > Microsoft.Scripting.ExtensionAttribute.dll > > When tried on two computers with IronPython installed and with the > source code files, the program worked. But it failed on another > computer that does not have these. And error message was very > generic .NET error. I don't exactly remember what it was. Is this > normal? > > Btw, since I have SharpDevelop installed, do I have to install > IronPython in order to write programs in IronPython? Or does it matter > which version of IronPython I install. The answer seems to be "No" > because I see those .dll files for IronPython in this folder "C: > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings > \PythonBinding" which are dated Feb 2009. Guess they're not the > latest. > > Thanks, > > Kelie > > ___ > 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
[IronPython] Problem with Creating Executable using SharpDevelop
Hello, I created a simple program with a few buttons, checkboxes, textboxes, etc. and it worked fine. The form was created in the latest SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the solution. In the release folder there were these files: IronPython.dll ManningsSolver.dll ManningsSolver.exe Microsoft.Scripting.Core.dll Microsoft.Scripting.dll Microsoft.Scripting.ExtensionAttribute.dll When tried on two computers with IronPython installed and with the source code files, the program worked. But it failed on another computer that does not have these. And error message was very generic .NET error. I don't exactly remember what it was. Is this normal? Btw, since I have SharpDevelop installed, do I have to install IronPython in order to write programs in IronPython? Or does it matter which version of IronPython I install. The answer seems to be "No" because I see those .dll files for IronPython in this folder "C: \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings \PythonBinding" which are dated Feb 2009. Guess they're not the latest. Thanks, Kelie ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
