Update solution to support targeting netstandard2.0

[haydenhall]

Replaced dependency on OleDbConnection to OdbcConnection and corrected connection strings.
Updated csproj files to the new project file standard and added netstandard2.0 as the target
Updated ModelGenerator and Unit Test projects to target net461
Updated NUnit to latest version

Requires dotnet cli to be installed to ensure latest MSBuild is called.

[milkshakeuk]

to make this build on your build server you will need to install Build Tools for Visual Studio 2017

[milkshakeuk]

This pull request will fix #61

[dreaminhex]

Migration to netstandard2.0 and .NET 4.6.1 approved.

[dreaminhex]

Merged to master. Solution is now up to date.

[milkshakeuk]

@Usualdosage it wasn't quite ready to be merged since there was no way to testing the output without a copy of the Hl7 Normative Database since it's used to generate the classes.

Granted it should work, however I was waiting to here back from hl7.org about optaining a copy the database for nhapi.

Also I have since updated the code to support net35 aswell so as to not be a breaking change.

I just haven't pushed the code to the PR branch yet.

[dreaminhex]

Decided it was worth it as this solution really needed to be upgraded (I upgraded locally before I started contributing). Thanks for the work.

[milkshakeuk]

@Usualdosage Ok but I would probably reverse it until it's fully tested (the source code generator).

And at the very least we shouldn't publish a new nuget package until it's fully tested.

@duaneedwards at some point we should set up a CI/CD pipeline to allow auto publishing the output of a release branch or successfully merge request to nuget.org, I can help set that up when we're are ready for that.

[dreaminhex]

I'd rather not reverse it, but will not be publishing to NuGet for some time, until this source has more time in test. Most consumers should be using NuGet right now anyway.

I'd appreciate any help setting up a CI/CD pipeline. I'm not sure how active @duaneedwards is on this project, but I am and will be. Thanks!

[jakubsuchybio]

I will gladly help with CI/CD pipeline. Are you thinking about Github Actions?

[milkshakeuk]

@Usualdosage looks like it was closed without being merged anyway.

@jakubsuchybio what steps where you thinking of adding to Github Actions

[jakubsuchybio]

It depends what we want from it.

• I can see some scripts in the root level for testing and deployment, so that can be automated
• I can see some Nunit tests, so those could also be automated for every commit/pr
• Whatever makes the biggest sense. Maybe some linting also.

[dreaminhex]

@Usualdosage looks like it was closed without being merged anyway.

@jakubsuchybio what steps where you thinking of adding to Github Actions

@milkshakeuk I think I didn't hit confirm, so we're good. I do want to merge it at some point though, so I'm going to reopen it. Any news on getting the Normative DB? I saw the comments from Duane about the price. Seems like we could work out something with them.

[milkshakeuk]

Any news on getting the Normative DB? I saw the comments from Duane about the price. Seems like we could work out something with them.

@Usualdosage I am still waiting to hear back from them, I originally emailed them on the 11th of October. but I have been told the following in their online chat.

This is not a standard question, and there is a legal aspect to it, the answer may take some time for that reason ;-)

[milkshakeuk]

It depends what we want from it.

• I can see some scripts in the root level for testing and deployment, so that can be automated
• I can see some Nunit tests, so those could also be automated for every commit/pr
• Whatever makes the biggest sense. Maybe some linting also.

@jakubsuchybio I think we should create a project board of things we want to do, CI/CD being one of them that way we distract this PR with unrelated conversation.

Once this is done, then you could do a PR to address the ticket.

In regards to what we might want...

• Build the base projects
• Run the source code generator
• Run the linter? (maybe use StyleCopAnalyzers along with .editorconfig to define style rules?
• Execute the unit tests
• Generate the NuGet package (auto increment the build NuGet package version (maybe based on branch name?)
• Create a release (in GitHub - only when we choose to do so since there might be come ceremony as part of this i.e. release notes etc not sure yet.)
• Upload to nuget.org (only when we choose to publish)

There should be slightly different rules regard in regards to whether it's a change to a new or existing branch or a pull request etc.

If the linting or unit tests fails the Merge Request won't allow merges etc.

[milkshakeuk]

@Usualdosage if you check the online chat it looks like it might be all but approved.

I asked if they had received the email and this was the response.

yes, and it has made the rounds through HQ for approval. Still working on the backend recordkeeping but @frank Oemig can send you the latest db - or would you prefer Jake downloads it from the HL7 site?

Hopefully won't be long now before we can run against the normative database.
If we want to release a version of NHapi which has had no changes to the generated class but supports netstandard we could do so with my changes, then when we run the generator whatever changes come from source code generator could be released as a patch, minor or major version update depending on what has actually changed.

@duaneedwards in order for us to pubish any new nuget packages officially we will need your support since you have the nuget.org credentials.

@duaneedwards what's your opinion on the version (adding support for netstandard on top of net35) being a minor version change, since no generated classes have been modified?

[duaneedwards]

@Usualdosage @milkshakeuk Can you please let me know your nuget.org usernames, and I'll add you to the nHapiNET org which should let you setup api keys / push new nuget packages etc

[duaneedwards]

Personally, I'd lean towards making it a major version change if all of the recent changes are bundled in with the .net version changes just to err on the side of caution.

What I'd do, would be to release a new major version behind a pre / alpha tag. Then let it stabilise over a couple of releases then remove the pre / alpha tag once people are confident with new releases. As there isn't a lot of test coverage in this solution it's a bit hard to ship a lot of changes confidently. So putting all the new changes behind a new version should let you move forward and work through anything that comes up, leaving the current version for legacy consumers.

I've been burned in the past by accepting PRs that ended up causing trouble in production, so I'd tend towards being more cautious than usual. But if it's a pre / alpha release than consumers will know what they are getting into by using it.

[milkshakeuk]

@Usualdosage @milkshakeuk Can you please let me know your nuget.org usernames, and I'll add you to the nHapiNET org which should let you setup api keys / push new nuget packages etc

@duaneedwards my nuget.org username is milkshakeuk

[duaneedwards]

@milkshakeuk invite sent.

[dreaminhex]

@Usualdosage @milkshakeuk Can you please let me know your nuget.org usernames, and I'll add you to the nHapiNET org which should let you setup api keys / push new nuget packages etc

@duaneedwards My Nuget username is Usualdosage

[dreaminhex]

@milkshakeuk Are we still holding off on merging this until we get the Normative DB?

[milkshakeuk]

@Usualdosage Ideally I would like to run against the normative database at least once, but I do know it should build and pack fine without, so if I don't get the opportunity to do that in th next few days then I guess we can just merge it and get a pre release NuGet package out.

[milkshakeuk]

@Usualdosage @duaneedwards preview package is on nuget.org https://www.nuget.org/packages/nHapi/3.0.0-preview.1