On Sun, Jun 19, 2011 at 11:07 PM, Markus Schaber <[email protected]> wrote: > Are there no 3rd-party applications which embed and install IronPython > with their own installer? > > Being afraid of such scenarios was the main reason why we build > IronPython on our own (with changed assembly name and signing key) and > install that customized version with our CoDeSys installer.
Yes, but I think everyone chooses the same path you do (rebuild/resign). At least, I'm pretty sure that's what Resolver One does (I don't know of any other apps ... maybe we need a "Who's Using?" page). The official installer is downgrade-proof, so other apps should just be using that; if anyone else unconditionally puts the IronPython files in the GAC, I'm not sure there's much we can do about it, sadly. Polite requests and public shaming is about it. For embedding, I would recommend you continue what you're doing - it's just just straight-up safer. It's a shame zipimport doesn't work; we could cut the deployed size of the stdlib down significantly. > > (The other reason was some suspected collision between the versions > compiled for .NET 2.0 and 4.0. We wanted to avoid problems if users > install their own IronPython versions. Nowadays, I'm convinced that this > problem only arises if you compile an application for .net 4.x which > references an IronPython dll compiled for .NET 2.x. Different signing keys for .NET 2 and .NET 4 would solve that. Since we don't build for .NET 2 anymore it shouldn't be an issue, right? - Jeff _______________________________________________ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
