Tag: .net

Python.NET and VS2010/.NET 4

I hope this will help some people like me searching for an answer. Several steps were mentioned in the Python for .NET mailing list by other people as well, but I haven’t seen a step-by-step guide. It is not my intention to duplicate other posts in that sense, but rather have all-in-one post.

Here is how I’ve got VS2010 and .NET 4.0 working with the revision 122 of the Python.NET having Python 2.6 installed.

Compile

  1. Get the sources (tarball from sourceforge or directly from SVN)
  2. Open the pythonnet.sln with VS2010 and convert to 2010 format (will happen automagically)
  3. [updated] Add the constructorbinding.cs to the Python.Runtime.csproj project (see also this post in the PythonNET mailing list)
  4. Change the target framework to 4. Follow the following step for EACH project
    Right-click on the project name and select “Properties”
    Select the “Application” tab on the left (if not selected yet)
    Change the “Target framework” to “.NET Framework 4”
  5. Open the buildclrmodule.bat and change the following lines (2 times!)

    %windir%\Microsoft.NET\Framework\v2.0.50727\ilasm /nologo /quiet /dll %ILASM_EXTRA_ARGS% /include=%INCLUDE_PATH% /output=%OUTPUT_PATH% %INPUT_PATH%

    to

    %windir%\Microsoft.NET\Framework\v4.0.30319\ilasm /nologo /quiet /dll %ILASM_EXTRA_ARGS% /include=%INCLUDE_PATH% /output=%OUTPUT_PATH% %INPUT_PATH%
  6. Open the clrmodule.il and change the lines with the version number in the following piece of code.assembly extern mscorlib
    {
    .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
    .ver 2:0:0:0
    }

    to

    .ver 4:0:0:0
  7. Recompile the whole solution, ignore the deprecation warnings.

Now you have all necessary files under the pythonnet folder where you have the sources. You need clr.pyd, python.exe and Python.Runtime.dll.

Test

  • Run the newly compiled python.exe
    Type the following in the interactive prompt

    >>> import System
    >>> print System.Environment.Version
    4.0.30319.1

    The last line proves that you’re using the 4.0 runtime. The precompiled binaries available from SourceForge would show


    2.0.50727.3615

NUnit and “The configuration section for Logging cannot be found in the configuration source.”

This time a leak from my professional life (read “what I am making money with”). I have habit of writing unit tests for all the business logic code, which leads sometimes to over-relying on the outcome of the unit tests, but that is not what I want to share now. In this case the tests that were running happily for several months, but then ‘suddenly’ stopped working on my test machine puzzling me with the following exception:

System.Configuration.ConfigurationErrorsException : The configuration section for Logging cannot be found in the configuration source.

What? I have copied all the files (that’s a ‘normal’ mistake), recompiled, re-checked the contents of them. No luck. So the last resort was to check the opinion of the NUnit (upgraded from NUnit 2.5.2 from 2.5.7) regarding the configuration file to be loaded for the test DLL. While it seemed all OK several times, when I really looked in the details I was not delighted. And here is why.

Open the NUnit configuration under NUnit | Project | Edit | General | Configuration File Name and check carefully what file name it expects to find.

By default NUnit seem to take <dll_name_without_extension>.config, while we had <dll_name>.dll.config. It all worked fine months before, but now it didn’t.

Just changing the file name to the correct one restored the happy green bar in NUnit.

This cost me about half-an-hour of compile-debug-stare-pull-hair exercise :(. Arggghhhh…