If things get really bad, you could execute two separate python interpreters
and communicate via an RMI solution, such as say, PYRO. It's a hack. But it
might work for the time being?
On Mar 22, 2012, at 4:59 PM, Tribble, Brett wrote:
> I would say you could just dupe the projects under the s
I would say you could just dupe the projects under the solution and change the
target info, but how are you going to control which one handles imports IE
"import System"?
From: pythondotnet-bounces+btribble=ea@python.org
[mailto:pythondotnet-bounces+btribble=ea@python.org] On Behalf Of
might any of this help?
http://stackoverflow.com/questions/2455654/what-additional-configuration-is-necessary-to-reference-a-net-2-0-mixed-mode
http://stackoverflow.com/questions/3267491/when-linking-a-net-2-0-managed-assembly-from-a-net-4-0-application-which-fram
see the answer by “htw”
http
I make a reference to System, I need to do it through from clr.
>>> import System
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named System
>>> import clr
>>> clr.AddReference("System")
>>>
So I figured if I had a 'import clr_2',
Then the call
The one lib that has issues, includes some cpp runtime stuff that needs to be
changed.
I’ve done it in the past, but it was a pain and is not our production code –
which I need to test.
All the other .NET libs that I use targeted against 2.0, worked in the 4.0 .NET
python.
From: Brad Fr
Silly question: isn't a .net 2.0 assembly backwards compatible with a .net 4.0
runtime? Why do you actually need to run a physically separate runtime? What
is breaking?
On Mar 22, 2012, at 4:27 PM, "Liam Corrigan"
wrote:
> Hi guys,
> I’ve been using python .NET 2.0 in python 2.7.2 successfu
Hi guys,
I've been using python .NET 2.0 in python 2.7.2 successfully for some
time now and have also used the .NET 4.0 version, but of course I need
to replace the clr.pyd and Python.Runtime.dll with the .NET 4.0
versions.
Although most of my 2.0 libs work over the 4.0 version, there is one in
