This project has moved and is read-only. For the latest updates, please go here.

ironpython - imports from references


when I work with ironpython environment, imports from standard .net assemblies are visible to Intellisense.
However assemblies included in the project references are not.
I have tried 2.1 beta and latest developer build.


jj995 wrote Aug 20, 2014 at 11:18 PM

I'm having this problem as well. I read the related thread at . I'm using VS 2010 with PTVS 2.1.20808.00 . I could try VS 2013 if anybody thinks that it would work in a new VS version.

My foo.dll is generated by a C# project "foo". I've tried both adding a reference via the project tab (selecting project foo) and the browse tab (selecting foo.dll in build output location), and neither method resulted in intellisense working. It always has a green squigly line under the foo in the "import foo" line, with the following hover over message:

Unable to resolve "Foo". IntelliSense may be missing for this module.

Intellisense is working for me with standard .net assemblies. Can anyone confirm intellisense working on an imported .net dll?

Zooba wrote Aug 29, 2014 at 10:00 PM

You will also need a clr.AddReference('') line in your code before the import statement. If you already have this (or one of the similar functions), then we presumably have an issue, but I'll need some more details about your project layout (ideally a copy of the not-working projects so I can test and debug them directly).

I can confirm that it does work on VS 2010, though there is a problem where if you change the code in the DLL and rebuild we don't always update our view of it. Closing/reopening the solution should deal with this.

paweljasinski wrote Aug 29, 2014 at 11:28 PM

One project creates a dll and makes a copy of it in a post build step:
xcopy /Y "$(TargetPath)" ..\..\..\extractor\eax\lib
xcopy /Y "$(TargetDir)Cheafcso.Eamod.Docgen.Common.pdb" ..\..\..\extractor\eax\lib
And it is referenced from the python:
clr.AddReferenceToFileAndPath(os.path.join(os.path.dirname(__file__), r'lib\Cheafcso.Eamod.Docgen.Common.dll'))
# pylint: disable=import-error
import Cheafcso.Eamod.Docgen.Common

# pylint: enable=import-error
Both projects are part of a solution.

Zooba wrote Aug 30, 2014 at 12:04 AM

The AddReferenceToFileAndPath call is probably the issue - we aren't quite smart enough to figure out a local path from __file__ and os.path calls without actually running your code. (In fact, we really just pass the literal string value through, so anything more complicated than a string constant isn't going to work :( .)

There's certainly some more intelligence we could add here, but I'm afraid we haven't and there isn't much of a workaround. If you add 'lib' as a Search Path and use AddReference() instead of AddReferenceToFileAndPath() then you should get correct behaviour in the editor and at runtime, but I appreciate that you can't always make a change like that (you also need to set IRONPYTHONPATH on the target machine, or manually edit sys.path at runtime).

paweljasinski wrote Aug 31, 2014 at 3:11 PM

I assume, in addition of making direct refrences with AddReference, the assemblies or projects have to be added by hand to pyproject references.
In small clean project, it works as expected (with minor bug which I will file separately). In case of my big and probably convoluted project I see consistently one of the cores spinning. I am not able to deduct pattern when it works and when it doesn't.
Since I will work on it this week, I will keep eye on symptoms and post update if anything usable comes up.
One of the things which I can try, is to recreate solution and pyproject from scratch.

Zooba wrote Sep 2, 2014 at 9:54 PM

Yes, that's basically what's involved. Far too many steps, frankly, but it's been hard to justify the tradeoff between fixing bugs that affect 50+% of users and fixing UX issues that affect <10% (the latter are normally more fun).

If you attach to the VS that is spinning the CPU and grab our symbols from the Microsoft Symbol Server, you may be able to give us a few stack traces from that thread. Often a fix for something like that is pretty obvious once you know where to look.

paweljasinski wrote Sep 10, 2014 at 9:34 PM

I worked for over the week without Resharper, I have never got a spin-out. Once I enable it, one core spins permanently. At least it doesn't crash.
I have created another issue where removal of a referenced assembly errors. I suspect it make no sense to further investigate until the other one gets taken care off.

paweljasinski wrote Sep 10, 2014 at 9:36 PM