<html><head><style type="text/css" media="screen">Body{font-family: Verdana;font-size:.75em;}h4{font-size:.9em;}a{color: #3a62a6;}.digest .toc {margin-bottom: 15px; padding-bottom:8px; border-bottom: 1px solid #ccc;}.digest .tocItem {margin-bottom: 15px;}.tocItem a{color:#000;text-decoration: none;}.tocItem a:hover{color: #3a62a6;text-decoration: underline;}.topic{padding-bottom: 8px;margin-bottom: 20px; border-bottom: 1px solid #ccc;}.topicHeader{margin-bottom:10px;}.topicTitle{font-weight: bold;}.replies p{margin:0;padding:0;}.replies hr{width: 15%;text-align: left;margin: 0 auto 5px 0;border: none 0;border-top: 1px solid #ccc;height: 1px;}.reply{margin-bottom: 6px;padding-bottom: 4px;}.anchorMarker{color: #3a62a6;}.footer{color: gray;}</style></head><body><div class="digest"><p>Hi ironpython,</p><p>Here's your Daily Digest of new issues for project "<a href="http://ironpython.codeplex.com/">IronPython</a>".</p><p>In today's digest:</p><h4>ISSUES</h4><div class="toc"><div class="tocItem"><a href="#toc_issue_1">1. <span class="tocTitle">[New comment] IronPython.dll has wrong assembly version</span> <span class="anchorMarker">↓</span></a></div><div class="tocItem"><a href="#toc_issue_2">2. <span class="tocTitle">[New comment] IronPython.dll has wrong assembly version</span> <span class="anchorMarker">↓</span></a></div><div class="tocItem"><a href="#toc_issue_3">3. <span class="tocTitle">[New comment] IronPython.dll has wrong assembly version</span> <span class="anchorMarker">↓</span></a></div><div class="tocItem"><a href="#toc_issue_4">4. <span class="tocTitle">[New comment] Try in the browser crash</span> <span class="anchorMarker">↓</span></a></div><div class="tocItem"><a href="#toc_issue_5">5. <span class="tocTitle">[New issue] argument of type 'type' is not iterable reports type of the wrong argument</span> <span class="anchorMarker">↓</span></a></div></div><h4>ISSUES</h4><div class="topic"><a name="toc_issue_1"></a><div class="topicHeader"><span class="topicTitle">1. [New comment] IronPython.dll has wrong assembly version</span> <a href="http://ironpython.codeplex.com/workitem/35119">view online</a></div><p>User MarkusSchaber has commented on the issue:</p><p>"<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>"</p></div><div class="topic"><a name="toc_issue_2"></a><div class="topicHeader"><span class="topicTitle">2. [New comment] IronPython.dll has wrong assembly version</span> <a href="http://ironpython.codeplex.com/workitem/35119">view online</a></div><p>User delicb has commented on the issue:</p><p>"<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>"</p></div><div class="topic"><a name="toc_issue_3"></a><div class="topicHeader"><span class="topicTitle">3. [New comment] IronPython.dll has wrong assembly version</span> <a href="http://ironpython.codeplex.com/workitem/35119">view online</a></div><p>User jdhardy has commented on the issue:</p><p>"<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>"</p></div><div class="topic"><a name="toc_issue_4"></a><div class="topicHeader"><span class="topicTitle">4. [New comment] Try in the browser crash</span> <a href="http://ironpython.codeplex.com/workitem/35121">view online</a></div><p>User slide_o_mix has commented on the issue:</p><p>"<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>"</p></div><div class="topic"><a name="toc_issue_5"></a><div class="topicHeader"><span class="topicTitle">5. [New issue] argument of type 'type' is not iterable reports type of the wrong argument</span> <a href="http://ironpython.codeplex.com/workitem/35126">view online</a></div><p>User paweljasinski has proposed the issue:</p><p>"At the moment we have:<br />
<pre><code>>>> " " in 11
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'str' is not iterable</code></pre>
Expected:<br />
<pre><code>>>> " " in 11
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: argument of type 'int' is not iterable</code></pre>
"</p></div><div class="footer"><p>You are receiving this email because you subscribed to notifications on CodePlex.</p><p>To report a bug, request a feature, or add a comment, visit <a href="http://ironpython.codeplex.com/workitem/list/basic">IronPython Issue Tracker</a>. You can <a href="http://ironpython.codeplex.com/subscriptions/workitem/project/edit">unsubscribe or change your issue notification settings</a> on CodePlex.com.</p></div></div></body></html>