Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] IronPython.dll has wrong assembly version
2. [New comment] IronPython.dll has wrong assembly version
3. [New comment] IronPython.dll has wrong assembly version
4. [New comment] Try in the browser crash
5. [New issue] argument of type 'type' is not iterable reports type of the
wrong argument
----------------------------------------------
ISSUES
1. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User MarkusSchaber has commented on the issue:
"<p>We had similar problems. Another problem was when we updated the IronPython
DLL without also upgrading the DLR DLLs.</p><p>Our solution is that we compile
each IronPython version we ship on our own (including all dependencies like the
DLR Assemblies), with an unique version number, and signed with our own
key.</p><p>As the key is part of the assembly ID, this allows our self-compiled
IronPython DLLs to be identified unambigously, and they're not disturbed by
whatever "official" IronPython assembly happens to be around on the
system.</p>"-----------------
2. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User delicb has commented on the issue:
"<p>Had the same problem.</p><p>I did think about compiling IronPython myself
and chaning version, but that seemed like an overkill. So, I used ILMerge to
change assembly version number and wrote the script that does so for all
IronPython and DLR dlls.</p><p>One thing to note - if embeded IronPython is
going to be used with 3rd party apps that check version number (for example, I
wanted to use PyCharm and Eclipse as IDE for scripts that my application
executed using embeded IronPython), keep 2.7 part of version and change the
rest. PyCharm raised errors about unsupported python version when I changed
version to 2.9.9.9. I rewrote all assembly versions to 2.7.32768.32768 and
added binding redirect to app.config to always load 2.7.32768.32768
version.</p>"-----------------
3. [New comment] IronPython.dll has wrong assembly version
http://ironpython.codeplex.com/workitem/35119
User jdhardy has commented on the issue:
"<p>Even better, it's intentional *and* wrong. And it's my fault, because I'm
selfish. It's a long story, so bear with me.</p><p>Rewind, oh, about 6 years. I
worked on a project called NWSGI that provides a WSGI interface to IIS, which
allowed running Python web apps on IIS using IronPython. Now, it (obviously)
links against IronPython, and I thought it would be good if (a) IronPython were
in the GAC and (b) NWSGI were in the GAC then (c) apps could be deployed to IIS
with only some configuration settings.</p><p>If IronPython's AssemblyVersion
changed with every patch release, I would have had to rebuild NWSGI to match,
and I didn't want to do that. I don't think this was completely unreasonable,
as anyone who makes a library that embeds IronPython will have the same
problem. I also didn't know about [binding
redirects](http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx) at
the time either, and even once I did they seemed ugly.</p><p>Once I took over
the IronPython release process, I just kept the AssemblyVersion the same across
all patch releases ... but didn't do a very good job of making sure those
releases were *compatible* to avoid issues. The workaround is exactly what
Markus describes - build it yourself, with your own key, and you won't have any
issues. That is less than ideal, obviously.</p><p>To avoid this, IronPython 3
will provide unsigned assemblies by default, with an option for signed ones if
needed. Unsigned assemblies have all of the advantages of drop-in updates *and*
they're never loaded from the GAC, so if you have the assemblies next to your
.exe, they will always be used. The signed ones will also be there for the
cases that need them, but discouraged.</p><p>For 2.7.5 I'm less sure about what
to do. Sticking with a bad idea for consistency is still a bad idea. Fixing a
broken app is straightforward if ugly. (And reading closer, it looks like
[publisher policy
files](http://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx#BKMK_Redirectingassemblyversionsbyusingpublisherpolicy)
may be able to make it seamless - I swear the documentation wasn't this clear
years ago).</p><p>Ultimately this is something that has bugged for a while, but
since no one has really complained about it, I've never stopped to fix it.
However, since I tend to manage priorities using the squeaky wheel method,
maybe now is the time. :)</p>"-----------------
4. [New comment] Try in the browser crash
http://ironpython.codeplex.com/workitem/35121
User slide_o_mix has commented on the issue:
"<p>Silverlight isn't really supported anymore. None of the main people working
on IronPython keep it up as the demand has been VERY low for Silverlight
use.</p>"-----------------
5. [New issue] argument of type 'type' is not iterable reports type of the
wrong argument
http://ironpython.codeplex.com/workitem/35126
User paweljasinski has proposed the issue:
"At the moment we have:
>>> " " in 11
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'str' is not iterable
Expected:
>>> " " in 11
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'int' is not iterable
"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on
CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue
Tracker. You can unsubscribe or change your issue notification settings on
CodePlex.com.
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
https://mail.python.org/mailman/listinfo/ironpython-users
