lp:~brad-fie/fiecac/pythonnet

Branch merges

This import branch has no branches proposed for merge into it.

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

109. By barton_c on 2013-04-08

# BUGFIX: Accommodate new output path (x86 vs. x64) #

108. By barton_c on 2013-04-08

# Move DEBUG_PRINT to the Properties->Build page of the DebugWin Configuration. #

107. By barton_c on 2013-04-08

# FIXED: .sln and .csproj file configurations x86/x64 Mono/Win Debug/Release all reflected throughout #
# Added Conditional Reference <Choose> <When> elements to Python.Runtime.csproj => building for Mono on Windows #
# Added Required reference assemblies => building for Mono on Windows #

# R# Cleanup on pyimport.cs #
# Remove reference to the Python.Runtime project from Console.csproj #

# BUGFIX: TARGET_PLATFORM==x86 in buildclrmodule.bat #

106. By barton_c on 2013-01-28

Of course, for the previous to work, you'll be needing the project files to go with...
But we don't need another copy of that signing key laying around.

105. By barton_c on 2013-01-28

# Solution Configurations for each VS and MD - We'll release x86 and x64 binaries separately. #
  MonoDevelop will now share the solution and project files with Visual Studio quite nicely.
  In fact, MD refers to .mds files as MD 1.x Solution Files. Separate configs supports different
  character widths on each OS platform.
  Platform specific settings are due, in part, to the introduction of DllExport's requirement
  (which actually only applies on Windows) Hmmm... Perhaps the Linux guy will want to revert to Any CPU #

104. By barton_c on 2013-01-28

# NUnit issues begin to resolve themselves (amazing, really) since MD supports NuGet now,
   just grab NUnit and add it to /packages/.
   Honestly, though, I did have to trick NuGet into giving me the UnmanagedExport update.

103. By barton_c on 2013-01-28

# Visual Studio 2010 .NET 4.0 (with a little ReSharper thrown in) #
# The new C# clrmodule depends on RGiesecke.DllExport in new pythonnet/packages directory which was import via NuGet #
# The signing key finally landed in the correct directory #
# Not sure why the console/Console.csproj referenced Python.Test #
# Python.Runtime Assembly version bumped to 4.0.0.1 #
# Tool and Framework versions all bumped for .NET 4.0 #
# [Obsolete?] buildclrmodule.bat got a tiny note after cli research on clrmodule.il #

# EmbeddingTest remains in flux while issues with nUnit (version bump) get ironed out #

102. By barton_c on 2013-01-28

NOTE: All this maintenance led to the soon-to-be-committed DllExport enable module:
# Cleanup after much ildasm and research: .fixup, .vtentry, etc. are all handled by the build system since late .NET 2.0.
  So there's no need to import the platform any longer. There's no fear of conflict with Linux - Mono needs a
  completely different mechanism (clr.so) to get the "Late Binding" ball rolling. #
# There is a big chunk of notes taken regarding my findings #

# .ver 4:0:0:1 matches Python.Runtime's version #
# I've turned on options for USE_PYTHON_RUNTIME_VERSION and USE_PYTHON_RUNTIME_PUBLIC_KEY_TOKEN #
## The signing key was generated on Linux without any certification (to satisfy the build script) ##

101. By barton_c on 2013-01-27

# Add Signing Key #

100. By barton_c on 2013-01-27

Added new usage on "Overloads"