@tonyroberts why is this failing? VS 2015?

@denfromufa because you've broken the project files. You can see the errors yourself if you look at the build log.

This PR as it stands is a bit of a mess. It should only contain the commits that are relevant to the change you want to make. Maybe you should create a new branch in your repo of the develop branch and cherry-pick only the commits you want to submit, then re-submit a new PR. That would make it much clearer to see what you are actually doing (do you really want to include a commit from 2006 in this pull request??). Also please don't change all of the project files without good reason - I had a quick scan and saw several things that had been broken as part of this change (pdb files no longer deployed, defines overridden - presumably neither of these things were intended, but it's hard to tell with all the noise).

I disagree with your changes to have the msbuild project copy the clr.pyd to site-packages. Not only is it the wrong place to do it, it uses whatever python happens to be on the path and not the one you're targeting. Stick with using setup.py as that can do in-place builds (setup.py build_ext --inplace), build and install (setup.py install) as well as building distributions without installing (setup.py bdist_egg/bdist_wheel/sdist). Copying to site-packages for every build is the wrong thing to do, even if it was implemented correctly.

Also, to load an assembly from a full path use this:

from System.Reflection import Assembly
Assembly.LoadFrom(assembly_filename)

Then you will be able to import it. AddReference is supposed to be called with an assembly name, not a full path.

Maybe we can close this PR for now, and if there are still changes you want to make perhaps try again from a clean branch or fork.

1. the branch was messed up because I started making changes to master branch (always forget!!!) and merged to develop branch. I'm going to clean this mess this weekend.
2. The problem is inconsistent behavior in interactive console and script mode for loading assemblies with full path. But I should have done more research - IronPython's clr.AddReference() cannot load DLLs from full path by design. I'm going to fix this. But also IronPython has very clear docstring unlike pythonnet for this behavior.
3. How can I trigger setup.py as part of solution building in VS? Why is this not default behavior. Yes, now I see that manually adding post-build scripts is quite redundant and sometimes unwanted behavior.

Thank you for educating, this git workflow is quite different from central repository approach I'm used to.

Yeah the docstrings aren't that great :( In fact the documentation in general for this project is pretty light. It's something I've been meaning to do something about (setting up a readthedocs accout and putting together some sphinx docs) but I've not found the time so far.

If you want to build from visual studio why not just set your python path to include the build folder? Then you don't have to worry about copying it anywhere.

This maybe personal preference, but I don't like adding my folders to
sys.path because scripts become machine specific. And then what if I have
multiple versions/branches of pythonnet project on machine? Basically I
like centralized location like GAC for pythonnet. Another reason to trigger
setup.py is to check locally its working condition.

Quick search on docstring revealed sphinx-doxygen bridge called breathe to
support other languages, e.g. c#

https://breathe.readthedocs.org/en/latest/

On Fri, Sep 11, 2015, 12:27 PM Tony Roberts notifications@github.com
wrote:

Yeah the docstrings aren't that great :( In fact the documentation in
general for this project is pretty light. It's something I've been meaning
to do something about (setting up a readthedocs accout and putting together
some sphinx docs) but I've not found the time so far.

If you want to build from visual studio why not just set your python path
to include the build folder? Then you don't have to worry about copying it
anywhere.

—
Reply to this email directly or view it on GitHub
#102 (comment).