Publish nuget package

[mkosieradzki]

First of all thanks for open sourcing MSAGL and removing of "Windows-only" restriction from the license!

It would be great to have NuGet package in official repository or in a nightly feed.

[rassilon]

I wouldn't mind doing a PR for a NuGet package, but I'm not sure exactly what parts should be put into NuGet packages. i.e. should there be a Msagl.Common with Drawing and Msagl, with a separate Msagl.WinForms that depends on Msagl.Common and includes GraphViewerGDI.

Additionally, should the Silverlight, SharpKit, WPF stuff be packaged into separate NuGet packages as well? If so, which assemblies should be in each additional package?

Thanks,
Bill

[levnach]

Thanks Bill!
I think separate packages for WPF and Silverlight is the right idea.
Msagl.Silverlight should include these DLLs: MsaglSilverlight, MsaglDrawingSilverlight and GraphControlSilverlight.
Msagl.WPF should include Msagl.Common and Microsoft.Msagl.WpfGraphControl
I am not sure yet what Msagl.SharpKit has to contain. I will get back with it.
Thanks,
Lev

[mkosieradzki]

In my opinion it would be great to have a cross platform multi-framework package that would contain: Microsoft.Msagl.dll only. Silverlight and WPF-specific versions can both reference this package.

For example we are utilizing only the Microsoft.Msagl.dll (the legacy library published as MSR) to do only graph layout computation (that's what Msagl is basically for :) ). We have our own presentation logic.

[daveaglick]

I agree with @mkosieradzki - a package that just has the data structures, layout algorithms, etc. would be very handy.

[levnach]

Structures and algorithms for graph layout are contained in one project:Msagl.csproj. This project builds Microsoft.Msagl.dll. The GDI and WPF viewers reference this DLL and also Microsoft.Msagl.Drawing.dll.
Unfortunately Silverlight cannot reference directly Microsoft.Msagl.dll. So, another library, MsaglSilverlight.dll, is built from the same sources by the project MsaglSilverlight.csproj

[rassilon]

I'm guessing .Net 4.0 and Silverlight 5 for the two sets of projects?
Any objection to upgrading the Silverlight control .sln to VS 2013?

[levnach]

Yes, .NET 4.0 and Silverlight 5 is right. What solution do you have in mind? GraphControlSilverlight.sln loads fine in VS2013

[rassilon]

Based on the feedback it seems like these packages are the thing to do:

• Microsoft.Msagl
• Microsoft.Msagl.Drawing
• Microsoft.Msagl.GraphViewerGDI (with the display name saying WinForms of course)
• Microsoft.Msagl.WpfGraphControl
• Microsoft.Msagl.Silverlight (containing all of the Silverlight dlls against SL5)

It does seem that the assembly/file versions might need some TLC as well.
i.e. Msagl doesn't currently include Version.cs like Drawing and GraphViewerGDI

That way all of the packages can have the same version, either that or there would be more complicated Nuget pack command lines to pass in package dependencies. (since keeping NuGet pkg versions matching the assemblies is probably the simplest thing to do)

I've started on Msagl, Drawing, and GraphViewerGDI .nuspec and .symbols.nuspec files.
I hope to test those tomorrow night.

Bill

[mkosieradzki]

If I may suggest: It would be great to merge •Microsoft.Msagl and •Microsoft.Msagl.Silverlight into a single multi-platform nuget package.
This approach would really simplify multi-targeting.
In future it would be great place to add .NET Core FX/Mono/Xamarin versions of the package. I would be happy to create PRs for handling additional platforms better when I am less swamped at my job (in couple of weeks/months hopefully) and it will be not done yet ;).

[phrrngtn]

+1 for nuget package.I have a "hello world" GDI viewer working within an Excel Custom Task Pane and it is very exciting!

[birbilis]

why isn't a PCL library used for the project containing the data structures etc.?

[birbilis]

also, the folder structure is a bit of a mess, please see this post of mine in a pattern that could be used for multi-platform: https://zoomicon.wordpress.com/2015/06/05/structuring-physical-source-and-virtual-solution-folders-for-portability/

I could restructure it myself, but not sure what is the appropriate way in Git to move around files (not just remove from one place and add to other) so that other people can pull-in the changes, so that they can still sync with pending changes they had done

[dsaf]

@birbilis +1

This way it could be used for building cross-platform graph visualisation applications.

[dsaf]

@levnach Is this technology behind Visual Studio's DGML support?

[levnach]

Sure, Visual Studio can load a Dgml file

Sent from my Windows Phone

---

From: dsafmailto:notifications@github.com
Sent: ‎9/‎10/‎2015 8:22
To: Microsoft/automatic-graph-layoutmailto:automatic-graph-layout@noreply.github.com
Cc: Lev Nachmansonmailto:levnach@hotmail.com
Subject: Re: [automatic-graph-layout] Publish nuget package (#4)

@levnach Is this technology behind Visual Studio's DGML support?

---

Reply to this email directly or view it on GitHub:
#4 (comment)