Discussion:
[Python.NET] import clr_2, import clr_4 vs import clr
Liam Corrigan
2012-03-22 20:27:56 UTC
Permalink
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
house library targeted against .NET 2.0 that will not, without some
awkward hacks.

I need to be able to call into libraries written against both .NET 2.0
and 4.0, as separated calls - ideally, I'd like to have things such that
I can operate in a python script something like this:



import clr_2

import clr_4



clr_2.AddReference("MyDOTNET_2.0_BasedLib")

clr_4.AddReference("MyDOTNET_4.0_BasedLib")





Are there any settings in the source build that I can do, to kick out
two separate clr.pyd and Python.Runtime.dll's with new names and
matching .NET version support?





Liam Corrigan






This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Brad Friedman
2012-03-22 21:00:09 UTC
Permalink
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?
Post by Liam Corrigan
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 house library targeted against .NET 2.0 that will not, without some awkward hacks.
import clr_2
import clr_4
clr_2.AddReference("MyDOTNET_2.0_BasedLib")
clr_4.AddReference("MyDOTNET_4.0_BasedLib")
Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll’s with new names and matching .NET version support?
Liam Corrigan
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
_________________________________________________
http://mail.python.org/mailman/listinfo/pythondotnet
Liam Corrigan
2012-03-22 21:02:42 UTC
Permalink
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 Friedman [mailto:***@fie.us]
Sent: March-22-12 5:00 PM
To: Liam Corrigan
Cc: <***@python.org>
Subject: Re: [Python.NET] import clr_2, import clr_4 vs import clr



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" <***@allenvanguard.com> wrote:

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 house library targeted against .NET 2.0 that will not, without some awkward hacks.

I need to be able to call into libraries written against both .NET 2.0 and 4.0, as separated calls - ideally, I’d like to have things such that I can operate in a python script something like this:



import clr_2

import clr_4



clr_2.AddReference("MyDOTNET_2.0_BasedLib")

clr_4.AddReference("MyDOTNET_4.0_BasedLib")





Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll’s with new names and matching .NET version support?





Liam Corrigan





IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.

_________________________________________________
Python.NET mailing list - ***@python.org
http://mail.python.org/mailman/listinfo/pythondotnet

=


This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Tribble, Brett
2012-03-22 21:19:32 UTC
Permalink
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://blogs.msdn.com/b/dotnet/archive/2009/06/03/in-process-side-by-side-part1.aspx

From: pythondotnet-bounces+btribble=***@python.org [mailto:pythondotnet-bounces+btribble=***@python.org] On Behalf Of Liam Corrigan
Sent: Thursday, March 22, 2012 2:03 PM
To: Brad Friedman; ***@python.org
Subject: Re: [Python.NET] import clr_2, import clr_4 vs import clr

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 Friedman [mailto:***@fie.us]
Sent: March-22-12 5:00 PM
To: Liam Corrigan
Cc: <***@python.org>
Subject: Re: [Python.NET] import clr_2, import clr_4 vs import clr

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" <***@allenvanguard.com<mailto:***@allenvanguard.com>> wrote:
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 house library targeted against .NET 2.0 that will not, without some awkward hacks.
I need to be able to call into libraries written against both .NET 2.0 and 4.0, as separated calls - ideally, I’d like to have things such that I can operate in a python script something like this:

import clr_2
import clr_4

clr_2.AddReference("MyDOTNET_2.0_BasedLib")
clr_4.AddReference("MyDOTNET_4.0_BasedLib")


Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll’s with new names and matching .NET version support?


Liam Corrigan


IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
_________________________________________________
Python.NET<http://Python.NET> mailing list - ***@python.org<mailto:***@python.org>
http://mail.python.org/mailman/listinfo/pythondotnet
=
IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Liam Corrigan
2012-03-22 21:09:20 UTC
Permalink
I make a reference to System, I need to do it through from clr.
import System
Traceback (most recent call last):

File "<stdin>", line 1, in <module>

ImportError: No module named System
import clr
clr.AddReference("System")
<System.Reflection.Assembly object at 0x04ECDDC8>
So I figured if I had a 'import clr_2',

Then the call to 'clr_2.AddReference("System") would call the 2.0
version of System.





From: Tribble, Brett [mailto:btribble-***@public.gmane.org]
Sent: March-22-12 4:59 PM
To: Liam Corrigan; pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr



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.com-+ZN9ApsXKcEdnm+***@public.gmane.org
[mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of
Liam Corrigan
Sent: Thursday, March 22, 2012 1:28 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: [Python.NET] import clr_2, import clr_4 vs import clr



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
house library targeted against .NET 2.0 that will not, without some
awkward hacks.

I need to be able to call into libraries written against both .NET 2.0
and 4.0, as separated calls - ideally, I'd like to have things such that
I can operate in a python script something like this:



import clr_2

import clr_4



clr_2.AddReference("MyDOTNET_2.0_BasedLib")

clr_4.AddReference("MyDOTNET_4.0_BasedLib")





Are there any settings in the source build that I can do, to kick out
two separate clr.pyd and Python.Runtime.dll's with new names and
matching .NET version support?





Liam Corrigan





IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this in error, please notify the sender immediately and delete
it from your system. Communications using this system are monitored and
recorded for lawful business purposes.


This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Tribble, Brett
2012-03-22 20:59:10 UTC
Permalink
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.com-+ZN9ApsXKcEdnm+***@public.gmane.org [mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of Liam Corrigan
Sent: Thursday, March 22, 2012 1:28 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: [Python.NET] import clr_2, import clr_4 vs import clr

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 house library targeted against .NET 2.0 that will not, without some awkward hacks.
I need to be able to call into libraries written against both .NET 2.0 and 4.0, as separated calls - ideally, I'd like to have things such that I can operate in a python script something like this:

import clr_2
import clr_4

clr_2.AddReference("MyDOTNET_2.0_BasedLib")
clr_4.AddReference("MyDOTNET_4.0_BasedLib")


Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll's with new names and matching .NET version support?


Liam Corrigan


IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Bradley Friedman
2012-03-22 22:23:06 UTC
Permalink
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?
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”?
Sent: Thursday, March 22, 2012 1:28 PM
Subject: [Python.NET] import clr_2, import clr_4 vs import clr
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 house library targeted against .NET 2.0 that will not, without some awkward hacks.
import clr_2
import clr_4
clr_2.AddReference("MyDOTNET_2.0_BasedLib")
clr_4.AddReference("MyDOTNET_4.0_BasedLib")
Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll’s with new names and matching .NET version support?
Liam Corrigan
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
_________________________________________________
http://mail.python.org/mailman/listinfo/pythondotnet
Bradley Friedman
VFX and Animation
Consulting and Technology
http://www.fie.us/
brad-DLbl0k+***@public.gmane.org
Liam Corrigan
2012-03-23 17:17:40 UTC
Permalink
Opening up our existing products native lib output to mixed mode proved
to be a real pain, so I took your first suggestion Brett.

After changing the project to .NET 4.0, changing the target info to
'clr4.pyd' and changing all clr related strings in all the files to
clr4, I have it working.

In my implementation, all my custom rack code and .NET support are
called in from testlib
import testlib
twoDotOAssemblies = testlib.clr.ListAssemblies(True)
twoDotOAssemblies[0]
u'mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
fourDotOAssemblies = testlib.clr4.ListAssemblies(True)
fourDotOAssemblies[0]
u'mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'



I agree, it is fuzzy to me as to what is happening behind the scenes
when I do:

testlib.clr.AddReference("System")

<System.Reflection.Assembly object at 0x04FBFF58>
testlib.clr4.AddReference("System")
<System.Reflection.RuntimeAssembly object at 0x04FC0300>



...but for my purposes, it doesn't matter. I don't do any dot net calls
other than my custom packaged C# library functions in .NET.

When I do want to play in that realm, I use IronPython but I generally
just write what I need in C# and then call it in pythonnet

Thanks for the help!





From: Liam Corrigan
Sent: March-22-12 5:09 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr



I make a reference to System, I need to do it through from clr.
import System
Traceback (most recent call last):

File "<stdin>", line 1, in <module>

ImportError: No module named System
import clr
clr.AddReference("System")
<System.Reflection.Assembly object at 0x04ECDDC8>
So I figured if I had a 'import clr_2',

Then the call to 'clr_2.AddReference("System") would call the 2.0
version of System.





From: Tribble, Brett [mailto:btribble-***@public.gmane.org]
Sent: March-22-12 4:59 PM
To: Liam Corrigan; pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr



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.com-+ZN9ApsXKcEdnm+***@public.gmane.org
[mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of
Liam Corrigan
Sent: Thursday, March 22, 2012 1:28 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: [Python.NET] import clr_2, import clr_4 vs import clr



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
house library targeted against .NET 2.0 that will not, without some
awkward hacks.

I need to be able to call into libraries written against both .NET 2.0
and 4.0, as separated calls - ideally, I'd like to have things such that
I can operate in a python script something like this:



import clr_2

import clr_4



clr_2.AddReference("MyDOTNET_2.0_BasedLib")

clr_4.AddReference("MyDOTNET_4.0_BasedLib")





Are there any settings in the source build that I can do, to kick out
two separate clr.pyd and Python.Runtime.dll's with new names and
matching .NET version support?





Liam Corrigan





IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this in error, please notify the sender immediately and delete
it from your system. Communications using this system are monitored and
recorded for lawful business purposes.


This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Tribble, Brett
2012-03-23 18:28:10 UTC
Permalink
Scary voodoo. (not significantly scarier voodoo than what python.net itself does though)

Glad to hear you were able to make it work. I'll file this away under "things I hope to never have to duplicate".

From: Liam Corrigan [mailto:Liam.Corrigan-pQIqDjLNBDebII5o8exnGAC/***@public.gmane.org]
Sent: Friday, March 23, 2012 10:18 AM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Cc: Tribble, Brett
Subject: RE: import clr_2, import clr_4 vs import clr

Opening up our existing products native lib output to mixed mode proved to be a real pain, so I took your first suggestion Brett.
After changing the project to .NET 4.0, changing the target info to 'clr4.pyd' and changing all clr related strings in all the files to clr4, I have it working.
In my implementation, all my custom rack code and .NET support are called in from testlib
import testlib
twoDotOAssemblies = testlib.clr.ListAssemblies(True)
twoDotOAssemblies[0]
u'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
fourDotOAssemblies = testlib.clr4.ListAssemblies(True)
fourDotOAssemblies[0]
u'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

I agree, it is fuzzy to me as to what is happening behind the scenes when I do:
testlib.clr.AddReference("System")
<System.Reflection.Assembly object at 0x04FBFF58>
testlib.clr4.AddReference("System")
<System.Reflection.RuntimeAssembly object at 0x04FC0300>

...but for my purposes, it doesn't matter. I don't do any dot net calls other than my custom packaged C# library functions in .NET.
When I do want to play in that realm, I use IronPython but I generally just write what I need in C# and then call it in pythonnet
Thanks for the help!


From: Liam Corrigan
Sent: March-22-12 5:09 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr

I make a reference to System, I need to do it through from clr.
import System
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named System
import clr
clr.AddReference("System")
<System.Reflection.Assembly object at 0x04ECDDC8>
So I figured if I had a 'import clr_2',
Then the call to 'clr_2.AddReference("System") would call the 2.0 version of System.


From: Tribble, Brett [mailto:btribble-***@public.gmane.org]
Sent: March-22-12 4:59 PM
To: Liam Corrigan; pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org<mailto:pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org>
Subject: RE: import clr_2, import clr_4 vs import clr

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.com-+ZN9ApsXKcEdnm+***@public.gmane.org<mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org> [mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of Liam Corrigan
Sent: Thursday, March 22, 2012 1:28 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org<mailto:pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org>
Subject: [Python.NET] import clr_2, import clr_4 vs import clr

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 house library targeted against .NET 2.0 that will not, without some awkward hacks.
I need to be able to call into libraries written against both .NET 2.0 and 4.0, as separated calls - ideally, I'd like to have things such that I can operate in a python script something like this:

import clr_2
import clr_4

clr_2.AddReference("MyDOTNET_2.0_BasedLib")
clr_4.AddReference("MyDOTNET_4.0_BasedLib")


Are there any settings in the source build that I can do, to kick out two separate clr.pyd and Python.Runtime.dll's with new names and matching .NET version support?


Liam Corrigan


IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may contain information that is copywritten, privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately and delete it from your system. Communications using this system are monitored and recorded for lawful business purposes.
Watts, Wendy
2012-03-23 18:41:55 UTC
Permalink
Please remove me from your mailing list.



Thank you.







Wendy Watts

IT Recruiter



VTRIT

100 First Street, Suite 200 I San Francisco, CA 55120

t: 415.536.0871 I f: 415.536.1419

***@vtrit <mailto:mnielson-***@public.gmane.org> .com | vtrit.com





From: pythondotnet-bounces+wwatts=vtrit.com-+ZN9ApsXKcEdnm+***@public.gmane.org
[mailto:pythondotnet-bounces+wwatts=vtrit.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of
Liam Corrigan
Sent: Friday, March 23, 2012 10:18 AM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: Re: [Python.NET] import clr_2, import clr_4 vs import clr



Opening up our existing products native lib output to mixed mode proved
to be a real pain, so I took your first suggestion Brett.

After changing the project to .NET 4.0, changing the target info to
'clr4.pyd' and changing all clr related strings in all the files to
clr4, I have it working.

In my implementation, all my custom rack code and .NET support are
called in from testlib
import testlib
twoDotOAssemblies = testlib.clr.ListAssemblies(True)
twoDotOAssemblies[0]
u'mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
fourDotOAssemblies = testlib.clr4.ListAssemblies(True)
fourDotOAssemblies[0]
u'mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'



I agree, it is fuzzy to me as to what is happening behind the scenes
when I do:

testlib.clr.AddReference("System")

<System.Reflection.Assembly object at 0x04FBFF58>
testlib.clr4.AddReference("System")
<System.Reflection.RuntimeAssembly object at 0x04FC0300>



...but for my purposes, it doesn't matter. I don't do any dot net calls
other than my custom packaged C# library functions in .NET.

When I do want to play in that realm, I use IronPython but I generally
just write what I need in C# and then call it in pythonnet

Thanks for the help!





From: Liam Corrigan
Sent: March-22-12 5:09 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr



I make a reference to System, I need to do it through from clr.
import System
Traceback (most recent call last):

File "<stdin>", line 1, in <module>

ImportError: No module named System
import clr
clr.AddReference("System")
<System.Reflection.Assembly object at 0x04ECDDC8>
So I figured if I had a 'import clr_2',

Then the call to 'clr_2.AddReference("System") would call the 2.0
version of System.





From: Tribble, Brett [mailto:btribble-***@public.gmane.org]
Sent: March-22-12 4:59 PM
To: Liam Corrigan; pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: RE: import clr_2, import clr_4 vs import clr



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.com-+ZN9ApsXKcEdnm+***@public.gmane.org
[mailto:pythondotnet-bounces+btribble=ea.com-+ZN9ApsXKcEdnm+***@public.gmane.org] On Behalf Of
Liam Corrigan
Sent: Thursday, March 22, 2012 1:28 PM
To: pythondotnet-+ZN9ApsXKcEdnm+***@public.gmane.org
Subject: [Python.NET] import clr_2, import clr_4 vs import clr



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
house library targeted against .NET 2.0 that will not, without some
awkward hacks.

I need to be able to call into libraries written against both .NET 2.0
and 4.0, as separated calls - ideally, I'd like to have things such that
I can operate in a python script something like this:



import clr_2

import clr_4



clr_2.AddReference("MyDOTNET_2.0_BasedLib")

clr_4.AddReference("MyDOTNET_4.0_BasedLib")





Are there any settings in the source build that I can do, to kick out
two separate clr.pyd and Python.Runtime.dll's with new names and
matching .NET version support?





Liam Corrigan





IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this in error, please notify the sender immediately and delete
it from your system. Communications using this system are monitored and
recorded for lawful business purposes.

IMPORTANT LEGAL NOTICE

This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this in error, please notify the sender immediately and delete
it from your system. Communications using this system are monitored and
recorded for lawful business purposes.

Loading...