Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Enable Platform-Specific Resourcing (ditch the #defs)
See original GitHub issueNow that VS2017 is out (#92), it might be worth exploring a more structured/discoverable way to introduce and locate platform-specific resources and dependencies.
One thought is to use convention by default, and do a test for an assembly that has the same name as the current assembly + Platforms + moniker. So, in the case of ExtendedXmlSerializer:
ExtendedXmlSerializer.Platforms.NetCore<== .NET CoreExtendedXmlSerializer.Platforms.NetFramework<== .NET Framework
Additionally, once the assembly has been resolved and located, a simple call to register it with the current (internal) container (enabling the use of an ICompositionRoot) would be a very straight forward task.
Advantages of this approach:
- No more #defines (!)
- Clean separation of platform concerns
Disadvantages:
- Two more assemblies to account for in our solution and for NuGet.
- ? (Additional feedback welcomed)
Issue Analytics
- State:
- Created 6 years ago
- Comments:22 (22 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Ok it sounds good.
OK. 😃 I think the way to go for now is to do one project to multiple frameworks, like v1.0, and then for v3.0 we can revisit this, maybe for #107.
Since there is only one
#ifthis isn’t a big deal for 2.0, but I think for .NET Standard 1.x it will require many more#if’s, and that will be ugly, so having separate projects will be better then.Sound good?