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
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] with_statement in IronPython 2.6 Alpha
Why are we discussing the environment variable PYTHONPATH rather than
IRONPYTHONPATH? Does IronPython even look at the former?
On Thu, May 21, 2009 at 9:04 AM, Lepisto, Stephen P <
stephen.p.lepi...@intel.com> wrote:
> Elise,
>
>
>
> PYTHONPATH is an environment variable and can be set on Windows by going to
> Control Panel à System. Select the Advanced tab then click on the
> Environment Variables button. In the lower pane, click the New button and
> enter PYTHONPATH for the Variable name and enter the path or paths you want
> in the Variable value. Use semi-colons to separate multiple paths. Click
> OK, click OK, and click OK to exit.
>
>
>
> Note: Visual Studio needs to be closed then reopened for it to recognize
> the new environment variable (this is true for Visual Studio 2005 and
> earlier, I actually haven’t tested Visual Studio 2008 to see if it properly
> responds to a change in environment variables).
>
>
>
> As for adding a reference to an assembly from IronPython, I found good
> success with using AddReference() with sys.path.append() instead of
> AddReferenceToFile(). For example,
>
>
>
> sys.path.append(r"C:\Users\i-ellang\Documents\Infer.NET2.2\bin\Debug")
>
> clr.AddReference("Infer.Compiler")
>
> clr.AddReference("Infer.Runtime")
>
>
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Elise Langham (Elanit)
> *Sent:* Thursday, May 21, 2009 4:23 AM
> *To:* users@lists.ironpython.com
> *Subject:* Re: [IronPython] with_statement in IronPython 2.6 Alpha
>
>
>
> Hi Dave,
>
> Thanks for the reply- I’m running in the Visual Studio
> under debug. I don’t know how to set pythonpath on a windows machine
>
> Most of the info is for C shell and linux. I find that the with statement
> works fine when just using the command line ipy.exe but it can’t pick up
>
> The references to imported modules. The references work fine when running
> in Visual Studio though
>
>
>
> import System
>
> from System import Console
>
> from System import Array
>
> from System import IO
>
> import clr
>
> import sys
>
> sys.path.append(r"C:\Users\i-ellang\Documents\Infer.NET2.2\bin\Debug")
>
> clr.AddReferenceToFile("Infer.Compiler.dll")
>
> clr.AddReferenceToFile("Infer.Runtime.dll")
>
>
>
> think this only works when the .dlls are in the IronPython ipy.exe
> directory though.
>
> 'C:\\Users\\i-ellang\\IronPython 2.6’
>
>
>
> Hope you can help,
>
>
>
> Elise
>
> ___
> 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] Docstrings on stuff in clr module
Thanks! --- .NET newb On Thu, Apr 30, 2009 at 11:37 AM, Dino Viehland wrote: > There’s the format the compiler generates w/ the /doc: option – I’m not > sure how standardized it is but it’s at least consistent J When you > install the .NET framework SDK you get XML doc files for all of the .NET > framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... > (or some other language instead of en). > > > > We already support reading and producing __doc__ from these XML files > (using .NET’s xml reading support and just looking for the values we know we > need to pull out) it’s just that we do something different for IronPython’s > own doc strings. > > > > *From:* users-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *On Behalf Of *Jonathan March > *Sent:* Thursday, April 30, 2009 9:20 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Docstrings on stuff in clr module > > > > Is there a standardized protocol for XML docstrings? > Then what software would you use to process them? > > On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland > wrote: > > Yes - I've opened a bug (22235 - > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > > > > ___ > 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] Docstrings on stuff in clr module
Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland wrote: > Yes - I've opened a bug (22235 - > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0?
This release does not update the assembly version numbers. See comments here: http://ironpython-urls.blogspot.com/2009/02/ironpython-201-released.html From: Doug Blank To: users@lists.ironpython.com Sent: Saturday, February 21, 2009 8:32:11 AM Subject: [IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0? Unless my system is not unzipping the right files, it looks like IronPython-2.0.1-Bin.zip on page: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481 actually has the 2.0.0 binaries: $ cd IronPython-2.0.1 $ ipy.exe -X:ColorfulConsole IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> Does anyone else see this? -Doug -- View this message in context: http://www.nabble.com/IronPython-2.0.1-Bin.zip-contains-2.0.0--tp22136075p22136075.html Sent from the IronPython mailing list archive at Nabble.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
[IronPython] please document file version numbers
> file version changes with every patch so you can determine exactly what > version you have I can find no documentation of the relationship between release version numbers (e.g. 2.0.1) and file versions (i.e. 2.0.20209.0). I would suggest that the file version number be listed in the following two locations: 1. The release download page 2. The read-me file for the release. === From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, February 13, 2009 3:32 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0.1 ... Minor non-breaking releases are in-place upgrades ... But its file version changes with every patch so you can determine exactly what version you have. ... for minor versions not reving the assembly version is also a way of life.___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
