Closed lennartb- closed 1 year ago
MBulli
commented
4 years ago Thanks for the PR :)
We abandoned the test project some time ago because we couldn't get the VSTestHost working on VS2017. For the same reason it was never adapted to the at the time new tree feature. Thus, its okay to ignore it ;)
lennartb-
commented
4 years ago Figured as much :) I have some other stuff on my fork, such as an update to .Net 4.7.2 and the new csproj format, however I have no idea if that breaks anything. There are a number of test solutions included, I assume you used them to cover a number of different project types and older VS version. Can you give a short rundown how I could use these? I guess it's mostly manual testing, but I'd like to have at least smoke-tested my code before I submit PRs for anything more complex.
MBulli
commented
4 years ago Does the .Net Update break support with older VS versions? We always try to support 2015, 2017 and 2019. However, this is a real pain to do and it's always temping to cut of old versions like 2015. Moreover, we don't have any installed version of 2015.
The test solution is simply for manual testing. Just start an experimental instance of VS from VS and open the solution. It contains every supported project type and you can undo changes to it. That's basically the idea.
MBulli
commented
4 years ago About the changes with the package reference. Could you please describe shortly why the changes and what does it change? I don't know what PackageReferences are ;)
lennartb-
commented
4 years ago About the older VS versions: No idea, I only have 2019 available, but I think I have 2015 and 2017 installed on my work PC - I could check next week. But I don't know enough about VS extensibility to make assumptions about the minimum versions that are set in the manifest. I personally think losing VS 2015 support (for newer versions) wouldn't be the end of the world since older versions would still work - but that's your call of course and I don't know what long-term features you are planning or if it's just on basic maintenance (since this extension does one thing, and does it very well). I only make these upgrades to iron out some annoyances with TFS we have at work (which aren't even directly caused by the extension, it's an issue with the way VS is applying launch parameters and touching files that constantly end up as a pending change).
PackageReference is the current and recommended way to include NuGet packages in your .NET projects. You don't have a packages.conf file anymore, all dependencies are in the csproj without having to worry about file paths and such, it's only a single XML element with the name and a version of a package. You don't have to specify transitive dependencies anymore, those are implicitly resolved by NuGet (which is why there are a lot less packages specified now). Speaking of file paths - you don't need to check packages into VCS, they are locally stored on your PC and NuGet manages different versions of packages. There are also no more relative (or even absolute paths) needed, NuGet knows where to find them. There is an exception to the one VS C-dependency, I couldn't find an official package for it.
Apparently there are also performance advantages and better MSBuild integration. The former is subjectively true, I did this migration in our 20-project solution at work two years ago (with a lot of different NuGet dependencies), and package restore is now pretty quick, especially if the packages are already cached. It also integrates with the new .NET Core dotnet commands, i.e. dotnet restore in a solution folder automatically restores all packages for that solution.
PackageReference isn't supported in VS2015, but in comparison to packages.conf it is actively developed. Which means this PR would break developing in VS2015, but shouldn't affect the deployment to it.
MBulli
commented
4 years ago We don't have any long term features in the pipeline. We consider the extension 'feature complete' right now (well we did this in the past as well, but our users had a lot of ideas how to extend the software xD ). Irame and I don't have enough spare time to really work on this project, thus its in basic maintenance mode but we fail at doing so too if you look at the open issues.
We're also no experts on VS extension development we did everything by trail and error. If you could test the extension at work with older VS versions that would be great!
PackageReference isn't supported in VS2015, but in comparison to packages.conf it is actively developed. Which means this PR would break developing in VS2015, but shouldn't affect the deployment to it.
Sorry for the misleading formulation. Actually we're only interested that the extension works with older versions. The development of the extension can always be done in the latest version.
MBulli
commented
4 years ago Just tried to merge your PR but the SmartCmdArgs.csproj as no Nuget references anymore. Did I miss something?
MBulli
commented
4 years ago Okay, this is messy (not your PR). In order to support VS2015 only 14.0 references are allowed in SmartCmdArgs. For VS2017 features like CPS we added the SmartCmdArgs15assembly which references the 15 SDK (required for Microsoft.VisualStudio.ProjectSystem.Managed).
This works at runtime but fails a compile time. You can see the many version conflict warnings.
However, after migrating to package references by myself I couldn't get the extension working on VS2015 because SmartCmdArgs always loads Microsoft.VisualStudio.Threading, Version=15.0.0.0 (easy to see in ILSpy).
I don't know who adds this dependency at it is kinda annoying to figure that stuff out. Maybe someone can give me a hint how to analyze the dependency chain. But for now, I let it rest ...
Irame
Migrates all three projects to PackageReference. I couldn't test the Test project since it doesn't build and seems to be outdated in regard to the current structure of the main extension.
Had to re-submit since I accidentally used my master for the last request.