To anyone interested, following Christoph&#39;s suggestion has now worked! For the record (any my own reference, I&#39;m writing up my &#39;recipe&#39; here).<div><br><div>0) Install Vanilla Python and modules of choice -- here, the only external requirements are:</div>
<div>distribute</div><div>pyreadline</div><div>nose</div><div>numpy</div><div>IPython</div><div><br></div><div>I installed these using binaries available from Christoph Gohlke</div><div><br></div><div>1) Build pythonnet with VS2012 .NET 4 (Python.Runtime Build Options -&gt; Python27,UCS2</div>
<div><br></div><div>2) Use mt.exe to set the manifest (I created the following batch script)</div><div><div>set path=&quot;C:\Program Files (x86)\Windows Kits\8.0\bin\x64&quot;;%path%</div><div>mt.exe -manifest msvcr90.manifest -outputresource:python.exe;#1</div>
</div><div><br></div><div>Thanks Christoph for this tip!</div><div><br></div><div>3) You are done! Now, however, the point of #2 above was to get IPython working with pythonnet (and the audience here is probably interested in that issue too). I had to do #2 above because of the errors I was getting from pyreadline (discussed earlier in this thread). Once that was resolved with the manifest, I was able to use the following batch script to run IPython using the pythonnet python.exe. Place this into a file called ipythonnet.bat and put it in the same directory as the pythonnet python.exe. You should be able to call it from there and &#39;import clr&#39;.</div>
<div><div><br></div><div>@echo off</div><div>set path=&quot;C:\pythonnet\&quot;;%path%</div><div>set PYTHONPATH=&quot;C:\Python27\Lib\;C:\Python27\Lib\site-packages\;C:\pythonnet\&quot;;%pythonpath%</div><div>python.exe -c &quot;import sys; from IPython.frontend.terminal.ipapp import launch_new_instance; sys.exit(launch_new_instance())&quot; %*</div>
<div>exit /B %ERRORLEVEL%</div><div><br></div></div><div><br></div><div>*note* I still am using python.exe -c which according to Christoph is probably a bad idea, so suggestions for a way around this are welcome (maybe by running python.exe and loading the ipython-script.py file?).</div>
<div><br></div><div>Thanks everyone! Hopefully this means I can work happily between CPython and use the resources of our in-house .NET 4 tools within Python!</div><div><br></div><div>--john</div><div><br></div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 10:54 PM, John Burkhart <span dir="ltr">&lt;<a href="mailto:jfburkhart.reg@gmail.com" target="_blank">jfburkhart.reg@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thomas, Thank you for the link. It took me some time to read through, and it exposes my naivety to think that I believed I could simply just &#39;build Python&#39; with VS2012...<div>
<br></div><div>Paul, I have considered IronPython, and decided it is not the avenue I&#39;d prefer to pursue... However, that being said, the issue is that I want to be able to use .NET 4 assemblies we&#39;ve built in house as part of a project. The library is large, and well built and documented, and would be a core part of activities. Further, I plan to use numpy. IronPython is an option, and it would work, and ultimately may be the route...<div>

<br></div><div>Yet somehow, my preference it so stick with CPython. Both for philosophical and practical reasons. Philosophically, while I appreciate the port of numpy/scipy for C# (therefore IronPython), and despite &#39;hearing&#39; contrary, it seems like the project is quite alive and actively developed, I still find myself concerned for fragmentation.</div>

</div><div><br></div><div>Practically, I have concerns about the viability of IronPython and incorporation of all the CPython &#39;batteries&#39;.</div><div><br></div><div>We see technology change so rapidly, and languages are included. Yet, it seems Python has such a large community and momentum. I am confident that it will evolve and grow for some time.</div>

<div><br></div><div>Being faced with the challenge of interfacing Python and C# is providing a a great deal of new information and exposure to &#39;what lies beneath&#39;. Interesting, indeed.</div><div><br></div><div>I see Christoph&#39;s suggestion now, and will hope I can make that solution work for now!</div>

<div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Nov 6, 2012 at 5:44 PM, Paul Moore <span dir="ltr">&lt;<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>&gt;</span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><div>On 6 November 2012 16:16, Thomas Kluyver <span dir="ltr">&lt;<a href="mailto:takowl@gmail.com" target="_blank">takowl@gmail.com</a>&gt;</span> wrote:<br>

</div></div><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On 6 November 2012 16:02, John Burkhart <span dir="ltr">&lt;<a href="mailto:jfburkhart.reg@gmail.com" target="_blank">jfburkhart.reg@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>Is it at all common, or at least not so unique, to be forced to build your own Python, and is it something that would be reliable in a operational environment?</div></blockquote></div><div><br>As far as I know it&#39;s pretty unusual, especially on Windows, but not unheard of.<br>




<br>Have a look at <a href="http://bugs.python.org/issue13210" target="_blank">http://bugs.python.org/issue13210</a> for an idea of the changes made to release Python 3.3 using VS 2010. If you can replicate that, it sounds like it should be quite easy to move between 2010 and 2012.</div>


</div></blockquote><div><br></div></div></div><div>I&#39;d agree, it&#39;s pretty unusual. The big issue, as Thomas said, is likely to be with the build process (the solution files, etc).</div><div><br></div><div>I&#39;ve never encountered an extension that *required* a particular version of VS to build, so it&#39;s always a case for me of getting the version of VS which matches the version of Python I&#39;m using and building extensions with that, rather than the other way around. Having said that, Python.NET is a very special case, and I can imagine it might well be necessary here. It&#39;s quite ironic, actually, I just happened to look at Python.NET the other day for completely unrelated reasons. I had thought from what I&#39;d seen that it had stagnated (certainly there&#39;s no sign of a Python 3 version, which unfortunately made it useless for me). Anyway, best of luck. I don&#39;t have much else I can offer, but if you do hit issues, post them and I&#39;ll see if I can help.</div>

<span><font color="#888888">
<div><br></div><div>Paul.</div></font></span><div><br></div><div>PS I presume IronPython is not appropriate for your requirements?</div></div>
<br></div></div><div class="im">_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org" target="_blank">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>