Add a MonoDoc nuget package

[mhutch]

Fixes #228

[Therzok]

Does this fix https://github.com/mono/api-doc-tools/issues/227 ?

Otherwise, it won't work

[mhutch]

No, it doesn't

[mhutch]

@joelmartinez I added a bunch of comments :)

[mhutch]

Currently failing with

 /usr/local/share/dotnet/sdk/2.1.200/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(198,5): warning : A stable release of a package should not have a prerelease dependency. Either modify the version spec of dependency "SharpZipLib [1.0.0-alpha2, )" or update the version field in the nuspec. [/Users/builder/jenkins/workspace/Docs-MonoApiDocTools/monodoc/monodoc.csproj]

[joelmartinez]

Ok, I took a look at this, and it seems like the newer version of nunit changed something about the way paths are resolved (maybe the default working directory, or something) ... so as a result, a bunch of tests that have to load some assemblies are failing.

I played around and got some of them passing by making this one change:

diff --git a/mdoc/mdoc.Test/BasicTests.cs b/mdoc/mdoc.Test/BasicTests.cs
index cddbcbd..ef136aa 100644
--- a/mdoc/mdoc.Test/BasicTests.cs
+++ b/mdoc/mdoc.Test/BasicTests.cs
@@ -1,6 +1,7 @@
 using System;
 using System.Collections.Generic;
 using System.Linq;
+using System.IO;
 using Mono.Cecil;
 
 namespace mdoc.Test
@@ -18,7 +19,10 @@ namespace mdoc.Test
 
             if (!moduleCash.ContainsKey(filepath))
             {
-                var readModule = ModuleDefinition.ReadModule(filepath);
+                var testAssemblyFilename = this.GetType ().Assembly.Modules.First().FullyQualifiedName;
+                var testDirectory = Path.GetDirectoryName (testAssemblyFilename);
+                var assemblyToOpenPath = Path.Combine (testDirectory, filepath);
+                var readModule = ModuleDefinition.ReadModule(assemblyToOpenPath);
                 moduleCash.Add(filepath, readModule);
             }

But there are still some other tests failing ... I've got to focus on putting a release together, so I'm probably not going to be able to look at this for another two weeks or so (given upcoming travel, etc).

Is there a way that maybe the scope of changes could be scaled back a bit? I fully understand and agree that SDK style projects are much nicer, but maybe that should be a standalone change/upgrade from the monodoc nuget? same for some of the other changes in this PR ...

[mhutch]

@joelmartinez the reason I migrated to SDK style projects was specifically because it makes it much easier to define/build the nuget packages though. I can't really separate them.

[joelmartinez]

@mhutch ok, fair enough ... then could it perhaps be decoupled from upgrading nunit (assuming that was the change that otherwise broke the unit tests)?

[mhutch]

@joelmartinez unfortunately nunit 2.6.4 doesn't support netstandard... :(

[joelmartinez]

@mhutch gotcha ... ok, I'll try to keep working on getting the unit tests passing here, but as I mentioned above, this will probably land after I'm able to get 5.7 out (ie. in a few weeks) :)

[mhutch]

fair enough!

[kekyo]

Ping: I'm waiting packaged monodoc :) what suspended reason?

[joelmartinez]

@kekyo It is on my agenda to revisit this soon ... no specific ETA, but it's definitely on the agenda. The PR needs some changes to ensure the unit tests still pass, not to mention some recent master changes that will have to be carefully merged

[joelmartinez]

I'm going to be breaking out some of these changes into separate/individual commits ... starting with updating to the latest nunit. This way I can make sure that all the unit tests continue passing as we subsequently move to SDK style projects, etc