Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

netstandard-ization #23

Closed
9 of 10 tasks
jumpinjackie opened this issue Jan 26, 2017 · 2 comments
Closed
9 of 10 tasks

netstandard-ization #23

jumpinjackie opened this issue Jan 26, 2017 · 2 comments
Labels
task
Milestone
6.0m8

Comments

@jumpinjackie
Copy link
Owner

jumpinjackie commented Jan 26, 2017 •
edited
Loading

We should look at making at least the MaestroAPI portions netstandard-compatible so it can be used in .net Core, Xamarin, etc.

  • Must be netstandard compatible
    • OSGeo.MapGuide.MaestroAPI
      • Target netstandard2.0
      • Move incompatible classes out of MaestroAPI to either a full-framework bridge assembly or to the project where the type is primarily consumed
    • OSGeo.MapGuide.ObjectModels
      • Target netstandard2.0
      • Address issues reported by ApiPort
      • ApiPort: Do not use System.Drawing primitives (Point/Font/etc)arious UIs, use new BindingList<T>(originalList)
    • OSGeo.MapGuide.MaestroAPI.Http
      • Target netstandard2.0
      • Merge into MaestroAPI itself. This is to simplify the consumption story in .net core.
  • Nice to be netstandard compatbile
    • OSGeo.FDO.Expressions
      • Target netstandard1.6
      • Need a netstandard-compatible version of Irony (found one!)
  • Verify existing SDK story still works
jumpinjackie added a commit that referenced this issue Feb 3, 2017
@jumpinjackie
#23: This mega submission converts the OSGeo.MapGuide.ObjectModels pr…
b0b865e 
…oject over to the new portable csproj format targeting netstandard 1.4. This was determined to be the lowest possible version we can target with the minimal amount of destructive changes. A summary of the changes here:

 - Move the generated classes into OSGeo.MapGuide.ObjectModels. This is because the new csproj format does not maintain file-by-file references by default, and neither do I want to do the same thing.
 - Remove a whole bunch of un-used LoadFromFile and SaveFromFile methods from all the generated XML classes. This was originally generated by xsd2code and the usage of readers were incompatible when ported over to netstandard 1.4
 - Replace use of System.Drawing primitives (Color, Font) with our own equivalents (ColorInfo, FontInfo)
 - Update most projects in the Maestro solution to target .net Framework 4.6.1. This is the full framework version that lines up with netstandard 1.4
 - Replace usages of System.ComponentModel.BindingList<T> with List<T>. Where it matters that we should be passing a BindingList<T>, we have an AsBindingList<T>() extension method for such cases.
 - Replace usages of NameValueCollection with IDictionary<string, string>. This is to avoid having to pull in the System.Collections.Specialized nuget package.
 - Add a shim for Type.IsAssignableFrom()

Unit tests currently fail because the current NUnit runner is not compatible with netstandard projects. We're gonna port our unit tests projects over to xunit, which appears to be the "blessed" unit testing framework in the netstandard world.
jumpinjackie added a commit that referenced this issue Feb 3, 2017
@jumpinjackie
#23: Add missing file from previous commit
d585dfb
jumpinjackie added a commit that referenced this issue Feb 3, 2017
@jumpinjackie
#23: Add skeleton Xunit project
fef5276
@jumpinjackie
Copy link
Owner Author

Sigh!

After painstakingly porting OSGeo.MapGuide.ObjectModels to netstandard, the tooling as of VS2017 despite showing promise, is still not there

  • The nunit runner now can't run/load the test library (that now references the netstandard ObjectModels project)
  • Porting to xunit is not an option as there is no netstandard compatible version. The closest one we could use is one that requires our project target .net Core, which itself means our range of available packages is even smaller. In particular, it means we lose Moq, which is not an option.

Our testing story is in disarray and I'm not going to go any further on this until the situation improves.

@jumpinjackie
Copy link
Owner Author

Now that .net standard 2.0 is out the door. It's worth revisiting this.

@jumpinjackie jumpinjackie modified the milestone: 6.0m8 Aug 25, 2017
@jumpinjackie jumpinjackie mentioned this issue Sep 24, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
task
Projects
None yet
Milestone
6.0m8
Development

No branches or pull requests
1 participant
@jumpinjackie