Code cleanup and framework integrity

[eabase]

I suggest to do some code cleanup and solidify to use one .NET framework. ATM there are several referenced and it's unclear what is needed and used. In the worst case it bloats installation as it might require duplicate packages for different versions.

Tasks:

• [x] Remove unused code & imports
• [x] Use only one .NET framework version (which one?)
• [x] Update deprecated package requirements
• [x] Use either PackageReference or packages.config, not both, if possible.
• [x] Use same ToolsVersion in both *.csproj files: <Project ToolsVersion="Current" DefaultTargets="Build" ... "> see: here
• [ ] Move all github related assets & images to ./docs
• [ ] Move all pre-built libraries to ./libs.

[drusteeby]

I would also suggest to use the sdk project style for the .csproj. It has a few advantages that would solve a few of the above problems. 1.) No need for packageReference or packages.config, the packages get defined right in the csproj 2.) Can target multiple frameworks if wanted. 3.) It's much easier to manage project files because they are xml based and can be edited right in visual studio.

I will open a PR for this change, it's not much work to do and makes things cleaner.

[silahian]

closing this issue

[eabase]

@silahian

closing this issue

I don't see a PR linked to this, which would have closed the issue automatically, and I also don't see any of the tasks completed. So what exactly is the point of closing the issue manually?

[drusteeby]

@eabase I completed the unused usings task but the rest are still open

[drusteeby]

I've been busy job searching lately but I've got some time this week, going to reopen to get some of these done, especially the SDK project files.

@eabase what are the depreciated packages, perhaps that one is complete as well? I don't see any warnings for packages.

[eabase]

@drusteeby

what are the depreciated packages, perhaps that one is complete as well?

Yeah, I have not had time to get back to this project for months. So it's quite possible from the changes you already made, that the packages now get automatically updated. (Do they? How to check?)

[drusteeby]

@eabase "Depreciated" and "not the latest version" are not the same thing. It's not necessarily good to automatically update nuget packages. When a package releases a new major version (ex. from 3.2 to 4.0) there is the possibility that there will be breaking changes to be fixed. So no, they do not get automatically updated and neither should they. My question was if you saw any packages that are specifically depreciated. If not I'll mark that one done.