.net standard 2.0 support #45
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Baseline target for this project is netstandard1.6 (same as the .net core compatible port of Irony its referencing)
The previous attempt at this was targeting netstandard1.6, which required pulling in 50 bajillion NuGet packages to fill in the missing bits. This attempt targets netstandard2.0. Besides replacing System.Drawing.Font with a custom struct that carries the same information, everything else built without errors. Yay!
Like the ObjectModels conversion, targeting netstandard2.0 was mostly seamless with the small change of: 1. Needing to move ImageSymbolConverter out to its own full framework class library (OSGeo.MapGuide.MaestroAPI.FxBridge) where we can reference System.Drawing 2. Commenting out testing for raster type (that used the CLR type of Bitmap, which doesn't exist in netstandard2.0) in RuntimeMapLayer.cs 3. Have IMappingService.GetLegendImage and its implementations return a raw System.IO.Stream instead of System.Drawing.Image (that is not present in netstandard2.0) 4. Remove or replace references to anything under System.Drawing
…is is a pre-requisite to consume netstandard2.0 libraries, of which MaestroAPI is now one of. Also move ImageSymbolConverter to Maestro.Editors. The FxBridge project is now strictly a series of extension method classes to polyfill APIs that were renamed or removed.
- Add references to upstream dependencies in the test projects. This is a full-framework workaround to allow our existing test projects to be executable in the VS test explorer and hopefully allow our existing full-framework testing infrastructure to work as before. - Add missing shared assembly info source files to the converted netstandard projects. - Move OSGeo.FDO.Expressions up to netstandard2.0. This is needed to allow the referencing (full-framework) test project to fully pass. When OSGeo.FDO.Expressions was at netstandard1.6, it leaked out a required dependency to System.Runtime, which broke a few tests due to assembly manifest mismatch BS if referenced from the (full-framework) test project.
…unit-console path.
…version that is aware of netstandard2.0 support
- Download NuGet v4.3.0 client before running "nuget restore". This is the version that is netstandard2.0 aware and it not yet incorporated into the AppVeyor build images - Fix up OSGeo.MapGuide.MaestroAPI.Local.csproj in release configuration
…e we downloaded!)
…uget.exe to have precedence
…at was previously compatbility errors downgraded to the expected NU1701 warning), install the SHFB tools to ensure API docs can build again
- Disable building the SDK package parts for now. In light of netstandard support, this will need revising. We probably don't even need a SDK package anymore and just serve everything through NuGet packages. - Similarly, modify Doc/MaestroAPI.shfbproj to reduce the API documentation surface area. This is a stopgap measure until we look at an alternative documentation system. The only reason we needed SHFB was to produce CHM files, which serves as a nice documentation artifact to bundle into the SDK package. But since the SDK package may no longer be required, it means that SHFB could also be on the chopping block too. - Update installer to: - Just add files by wildcards (due to the explosion of dlls due to the piecemeal System.* nuget packages brought on by the netstandard libraries). - Require .net Framework 4.6.1. This is the full framework version that supports the .net standard 2.0 API surface.
…undant and all these files have been removed. - Fix various postbuilds to reference the machine-local nuget package cache path (as that's where all nuget packages are now installed to) - Reference netstandard (prerelease) versions of GeoAPI, NetTopologySuite and ProjNet - Update DockPanelSuite to 3.0.0
# Conflicts: # MaestroAPITests/MaestroAPITests.csproj # MaestroAPITests/packages.config # OSGeo.MapGuide.MaestroAPI.Http/OSGeo.MapGuide.MaestroAPI.Http.csproj # OSGeo.MapGuide.MaestroAPI.Local/OSGeo.MapGuide.MaestroAPI.Local.csproj # OSGeo.MapGuide.MaestroAPI.Local/packages.config # OSGeo.MapGuide.MaestroAPI.Native/OSGeo.MapGuide.MaestroAPI.Native32-2.2.0.csproj # OSGeo.MapGuide.MaestroAPI.Tests/OSGeo.MapGuide.MaestroAPI.Tests.csproj # OSGeo.MapGuide.MaestroAPI.Tests/packages.config # OSGeo.MapGuide.MaestroAPI/OSGeo.MapGuide.MaestroAPI.csproj # OSGeo.MapGuide.MaestroAPI/Utility.cs
- Fix the signing key path to be project-relative instead of solution-relative
…e> instead of Dictionary<string, IResource> For the HTTP implementation, use Parallel.ForEach in conjunction with ConcurrentDictionary<string, IResource> instead of using ThreadPool.QueueUserWorkItem()
… and will be maintained independently.
…e/mapguide-maestro into feature-netstandard2
…ution root (instead of some place in appdata) - Fix postbuild events of various projects now that nuget packages are back inside the solution root. - Change output paths of various projects back to bin\[Debug|Release] as we no longer will be making a SDK package - Add unittest.bat to easily run unit tests on Windows - Attempt to fix appveyor.yml - Remove SDK package building - Remove API documentation generation - Disable OpenCover and just run the unit tests as-is
… of transitive dependencies (brought by the switch over to PackageReferences)
…e start publishing to NuGet gallery as prerelease packages)
…gain if we hit it with xunit console runner against the full framework test assemblies. So restore this functionality.
YAML, where 2 stray spaces breaks the file validity. What a stupid markup language!
- Undocumented API members - Un-used usings - Classes that should be internal instead of public
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
netstandard2.0support forOSGeo.FDO.ExpressionsOSGeo.MapGuide.ObjectModelsOSGeo.MapGuide.MaestroAPInet461in addition tonetstandard2.0Other changes:
OSGeo.MapGuide.MaestroAPI.FxBridgeproject wherenetstandard2.0incompatible code has been relocated to. Mainly involves code that uses types fromSystem.DrawingConnectionProviders.xmlis only required if using the local (mg-desktop) provider or using a tool-generated (ie. ProviderTemplate) wrapper provider around the official MapGuide .net API.Microsoft.IO.RecyclableMemoryStreamto pool most usages ofSystem.IO.MemoryStreamin MaestroAPI/ObjectModels to reduce heap fragmentation and GC pressure.