Closed lucyllewy closed 7 years ago
oh, hang-on, I appear to have missed-off the web.config automatic updating.
that's better.
the changes between my previous comment and this are a rebased version of the original commits above.
both the issues highlighted by @weirdan are now fixed.
Could you also fix this?:
CSC: error CS1904: `CS0618' is not a valid warning number
It's in Source/Extensions/GetText/Extensions.GetText.csproj file.
Also, is it possible to nuget pack
with .nuspec
files instead of .csproj
? Nuget-mono doesn't seem to support packing with project files: http://stackoverflow.com/a/34394716/450611
Another improvement I would suggest is automatic package restore for non-VS environments. It's rather easy, just add another target and make BeforeBuild and BeforeRebuild depend on it
<Target Name="RestorePackages">
<Exec Command=""nuget" restore "$(MSBuildThisFileDirectory)..\..\Solutions\Phalanger.sln""/>
</Target>
with regards to building nuget packages under mono, this is known to fail for various reasons, including the one you cite, but also e.g. nuget/home#913
I've uploaded example builds of nuget packaging at http://go.bwlh.at/phalangernuget
Thats great! One question - how is the versioning handled?
at the moment it's done manually via editing the nuspec. We could possibly introduce a change to, or script in addition to, the file Tools/UpdateFileVersionFromChangeset.cmd
(and .sh equivalent)
Versioning is pretty important here, at least it must be in sync with https://github.com/DEVSENSE/Phalanger/blob/master/Source/Build/AssemblyInfoCommon.cs#L20 and the minor version below ... is it possible to make it somehow ? so the nuget package would have the same version
The commit 6974287 tells nuget to use the details in each project's metadata after they're compiled rather than being manually altered. This means that version numbers should be synchronised now as requested.
920e736 fixes nuget's building of packages complaining that version numbers were unspecified for projects depending on other projects in the solution (referring to ourselves).
2a16875 can be split-out to a separate merge if needed and is a simplification and unification of all the msbuild settings and tasks set in each .csproj file moving them all into the common build tasks and settings files where possible.
about version numbering. nuget uses SEMVER numbers which are different to the original .net method (three numbers instead of four). There's a discussion piece about the implications of nuget/semver with .net libraries.
Reference #37 This PR has many changes which are all aimed at nuget packages. I am able to successfully build locally and create .nupkg files which I am then able to install into a new ASP.NET application in Visual Studio. The resultant project is then able to successfully run PHP code. All that is required once the nupkg files are created is to point nuget at the files and install the core, core.parsers, core.codedom and classlibrary packages. Everything else is optional. Ideally we'll be able to create a metapackage which can pull-in the essentials in-one-go, but that's for the future.