Code cleanup and framework integrity about visualhft HOT 7 OPEN

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.

from visualhft.

closing this issue

from visualhft.

@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?

from visualhft.

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

from visualhft.

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.

from visualhft.

@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?)

from visualhft.

@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.

from visualhft.