Recent changes to patches

Add support for .NET 4.5

2013-12-02T17:43:38.825000Z

This patch adds support for .NET 4.5 and .NET 4.5.1.

There are two minor additional things that should be done and aren't included in this patch:
1. Update Prebuild.exe. I assumed you'll want to compile it yourself.
2. Add to the svn:ignore property of the "Prebuild" directory the following entry: "Prebuild.v12.suo". This is the SUO file creatd by Visual Studio 2013. I didn't add it because that made "svn patch" fail, for some reason.

Remove unnecessary build s in NAntTarget.cs

2012-11-14T03:34:51Z

For every nant .build file generated, Prebuild was adding a <copy> task to copy files from the base directory to the bin/Debug or bin/Release and then another copy task which ended up copying everything again into an embedded bin/Debug/bin/Debug or bin/Release/bin/Release directory.

It just so happened that nant 0.91 and probably earlier appeared to contain a bug which stopped those <copy> directives actually doing any copying. However, 0.92 seems to fix this (perhaps [1]) and so nant starts copying a bunch of files on every build that don't actually appear to be needed to perform the compile, at least in the OpenSimulator project.

This patch removes those copy statements and is really for possible comment since I don't know if it breaks other builds (though that seems unlikely with the previous nant bug).

[1] https://github.com/nant/nant/pull/39
[2] http://opensimulator.org

Add Copy task

2011-12-25T04:28:17Z

Adding Copy task for vs ...
<Match pattern="../bin/IronPython.xml" buildAction="Copy" recurse="false" destination="$(OutputPath)" />

/Work/BlueWall/Projects/BlueWall Advanced/Patch

2010-08-30T18:50:18Z

This patch provides changes to allow wildcards to be used in include definitions in the prebuild.xml file. There is also a fix for the nant target. When using the path element in Reference nodes, the nant build was getting only the path part to the reference, and not the reference name.

Added support for resource names (Visual Studio)

2010-05-17T23:19:45Z

Implemented support for \'ResourceName\' attribute on the Match and File nodes. The attributes value can contain the variables $(assemblyName), $(path), and $(filename) which are replaces with the respective values.

Assembly Name: The $(assemblyName) variable is replace the the hosting project\'s assembly name, if that project exists, otherwise a empty string is used.

Path: The $(path) is replaced with the relative path from the parent project with the directory seperator represented as a dot (i.e. \"Resources\\Pictures\" becomes \"Resources.Pictures\".
Filename: The $(filename) variable is replaced with the actual filename including extension.

Finally I\'ve also added a warning in Kernel.cs:488 in the case that it comes across an unexpected node (in my case I had the configuration nodes there instead of under the solution).

Note: I think this patch also includes the previous clean embedded solution fix and again only applies to the projects covered by VS Generic.

Oh and please don\'t feel obliged to check this in I just submitted it as the project I\'m working on required custom resource names and I thought I would share my changes :)

VS Target - Clean projects in embedded solutions

2010-05-12T00:08:23Z

There is currently a bug where projects in embedded solutions are not 'cleaned'. The attached patch fixes this for VS Generic targets only (VS2005,VS2008,VS2010).

Example:
<Solution name="SharpDebug" activeConfig="Debug">
<EmbeddedSolution name="Main">
<Project name="TestApp">
....
</Project>
</EmbeddedSolution>
</Solution>

In this example the project 'TestApp' will not be cleaned (project files are not removed).

Patch for VS 2010 support

2010-04-24T04:10:33Z

Introduces a new target for Visual Studio 2010 (Version 11.0), also adding support for Framework Version 4.0.

Start of adding support for Platform

2009-01-31T00:24:43Z

Adding in the start of specifiying platform so that you can compile to non-AnyCPU targets.

In Visual Studio, the platform is now called "Platform", not "Any CPU". This is to prevent confusion on what platform you are really compiling to. Visual studio supports picking both a Target (Debug) and a Platform (Platform) on each project. For proper Visual studio support, this should be an array of platforms, not a single one, and then you pick what the platform for the project.

Nant has a simpler view of that will match with how Prebuild views the target. Nant has the platform at the CSC level, so a Projects maps to a csc pefectly.

Patch for frameworkVersion attribute

2008-11-27T00:11:36Z

Adds support for the frameworkVersion attribute to VS2008 and VS2005. This patch was created against the DNPB checked into OpenSim's repository so there may be some weirdness applying it to trunk, but other than SVN revision numbers I think it should apply cleanly.

Patch for 3.5 & NoStdLib

2008-10-11T17:00:25Z

Contains three patches:

Support for .Net Framework 3.5 for VS and Mono
Support for <NoStdLib" option for VS Project and Nant Build files
Includes the remove empty project patch.

These patches are used in the MOSA project (www.mosa-project.org).