Hi Mark,
My understanding (and I might be wrong) is Pythonnet (Official Compiled
Master branch) is *not* compatible with .Net Core and is compatible only
with the .Net framework. Is it possible that you accidentally load .Net
Framework libraries when you think they are .Net Core ?
I spent a lot of time with a similar problem and I finally decided to
compile my project also for .Net framework :
.csproj:
<PropertyGroup>
<TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks>
</PropertyGroup>
There are forks that are supposed to be compatible with .Net Core but I
wasn't able to make them work either.
I hope it helps,
Emmanuel.
On Thu, Apr 9, 2020 at 12:46 PM Mark Mikofski <mikof...@berkeley.edu> wrote:
> Sorry for starting a new thread if redundant. I have been a long time user
> of PythonNet and suddenly I am having an intermittent failure that I can't
> diagnose,
>
> PythonNet == 2.4.0.dev0 from pypi in Conda
> Python == 3.7.6 from conda main channel
> msvc 2019
>
> I am using the following repository:
> https://github.com/mikofski/pv.net
>
> When I try to import pv.SolarPosition I get the following error:
>
> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
> location)
>
> I've tried it a couple of ways:
>
> 1. add reference to assembly name, doesn't work
> >>> import clr
> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
> >>> assy = clr.AddReference(assy_path)
> >>> import pv
> >>> pv
> <module 'pv' (namespace)>
> >>> pv.SolarPosition
> AttributeError: module 'pv' has no attribute 'SolarPosition'
> >>> from pv import SolarPosition
> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
> location)
>
> 2. add assembly path to PYTHONPATH or sys.path, neither works
> >>> import sys
> >>> assy_path = "C:\\Users\\mikm\\source\\repos\\pv.net\\bin"
> >>> sys.path.append(assy_path)
> >>> import clr
> >>> assy = clr.AddReference("pv")
> >>> import pv
> >>> pv
> <module 'pv' (namespace)>
> >>> pv.SolarPosition
> AttributeError: module 'pv' has no attribute 'SolarPosition'
> >>> from pv import SolarPosition
> ImportError: cannot import name 'SolarPosition' from 'pv' (unknown
> location)
>
>
> 3. import from clr, always works
> >>> import clr
> >>> assy_path = "C:\\Users\\mikofski\\source\\repos\\pv.net\\bin\\pv.dll"
> >>> assy = clr.AddReference(assy_path)
> >>> from clr import pv
> >>> pv
> <module 'pv' (namespace)>
> >>> pv.SolarPosition
> pv.SolarPosition
> >>> dates = ["19900101T12:30:00", "19900102T12:30:00",
> "19900103T12:30:00", "19900104T12:30:00"]
> >>> pv.SolarPosition(dates, 32.1, -121.0)
> 19900101T12:30:00 --> 1/1/1990 12:30 PM
> 19900102T12:30:00 --> 1/2/1990 12:30 PM
> 19900103T12:30:00 --> 1/3/1990 12:30 PM
> 19900104T12:30:00 --> 1/4/1990 12:30 PM
> 01/01/1990 12:30:00 --> 1.00
> 02/01/1990 12:30:00 --> 2.00
> 03/01/1990 12:30:00 --> 3.00
> 04/01/1990 12:30:00 --> 4.00
> 1.00 --> 0
> 2.00 --> 0.01721421
> 3.00 --> 0.03442841
> 4.00 --> 0.05164262
> Out[35]: <pv.SolarPosition at 0x173cdd71c88>
>
> Even though I still can't import SolarPosition from pv at least call
> pv.SolarPosition.
>
> Weirdly, somehow if I import some other assemblies, which sometimes works,
> or if I keep trying long enough, suddenly it works, and I can import
> SolarPosition from pv using method 1 or 2. I don't know why, it's not
> repeatable.
>
> I recently made changes to my visual studio configuration, I only have
> build tools for 2015, visual studio 2017, and visual studio 2019. I am
> building using the makefile with visual studio 2019. I have tried compiling
> with either 2015 or 2017, but it doesn't seem to matter. I am using the
> native x64 environment.
>
> Also, maybe this matters, I started this project in visual studio 2019 as
> a .net core 3.1 project, and I noticed that it doesn't have
> AssemblyInfo.cs or a very big csproj file, but since I'm compiling from
> the command line using csc in the Makefile (see repo) I didn't think that
> would matter.
>
> Also, I tried an older project that I started using .Net Framework-4.5 and
> it also seems to work intermittently, inconsistently. My suspicion is that
> I somehow screwed up my .NET configuration, but not sure how or what.
>
> Anyway, if anyone has ever encountered this, or has any ideas, please let
> me know. I'm going a little crazy.
>
> thanks,
> Mark
> _______________________________________________
> PythonNet mailing list -- pythonnet@python.org
> To unsubscribe send an email to pythonnet-le...@python.org
> https://mail.python.org/mailman3/lists/pythonnet.python.org/
>
_______________________________________________
PythonNet mailing list -- pythonnet@python.org
To unsubscribe send an email to pythonnet-le...@python.org
https://mail.python.org/mailman3/lists/pythonnet.python.org/
