VTS OOB developer story - desktop dependencies out of date. Vts.Desktop necessary anymore? about vts HOT 14 CLOSED

from vts.

Hi dcuccia,

Thanks for your feedback. Unfortunately, we just entered a transition period and you have caught some of our recent change errors. I'm sorry about that. Currently the Vts.Desktop project is needed for the WPF GUI. We are currently working on Xamarin Forms (XF) version and when this is complete, there will be no need for the desktop project. The XF solution cannot have multiple copies of libraries within the solution and there were conflicts with those libraries brought in by the resident XF code and those brought in by our Vts, so we have been trying to eliminate those packages that are not necessary to the Vts solution to enable the XF solution to compile using the Vts net standard nuget package. Keeping the Vts net standard, Vts.Desktop, the WPF GUI, and their associated unit tests, and the XF project all updated, compiling and passing unit tests has been a bit of a challenge lately, especially since many of the nuget packages we use get updated on a weekly basis and those bring in subtle changes.

So I appreciate your suggestions. If we can simplify our process so that when we push on one side something doesn't break on another, that would be great.

We'll get there. Your input will help us. So thanks again.

from vts.

from vts.

Hi David,

We still plan to keep the .NET Framework version of our software so we can support users who are on older versions of Visual Studio. We would also have to change the way we access the libraries for features like the MATLAB interoperability.

Your suggestion for adding a post build copy of the .NET Standard version of the library to the build folder was a good one. I added the post build command to copy Debug and Release versions of Vts.dll and Vts.deps.json to the build folder however when I try to reference the library from a similar .NET Core command line application, it does not pull the dependencies. Do you have any experience with these types of references?

from vts.

I agree with you that there should be a "simple" way to chain nuget dependencies but after searching many blog posts and articles on this and *.deps.json, I still have not found a way.

Here are a couple of the more useful articles that I found:
Scott Hanselman Blog Post
Nate McMaster Blog Post

I have tried everything suggested in these posts and more and I still cannot easily reference the .NET Standard library.

from vts.

From the Hanselman post, it seems like we'd just edit one line to the .csproj:

<RestoreProjectStyle>PackageReference</RestoreProjectStyle>

Tried this on my .Net Core command line project and it worked great. Tried on a .NET Desktop command line and it didn't work. This is the error I'm getting:

Referencing a .net standard class library project in .net Framework web app and System.IO.FileNotFoundException throws
dotnet/standard#410

...and I think these are the appropriate threads regarding the core issue:

Issues with .NET Standard 2.0 with .NET Framework & NuGet
dotnet/standard#481

Dependencies don't flow from new NETStandard project to old Desktop projects through ProjectReferences
dotnet/sdk#901

from vts.

Adding that line to the .csproj file did not work for me, I was still getting missing references. Which folder with the VTS library were you including as a reference? I tried the one in the bin folder as well as the one I just added to the build folder.

from vts.

When it worked on .Net Core, I was referencing src\Bts\bin\Debug\netstandard2.0\Vts.dll. It also has a Vts.deps.json file alongside it with all project dependencies. That said, I just tried on a new machine and couldn't reproduce, so very confused. Need to research more...here are a few breadcrumbs to myself:

NuGet/Home#4488
dotnet/sdk#757

from vts.

...and https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution

from vts.

Figured it out (or at least the work around). TL;DR: in the .Net Standard 2.0 Vts .csproj XML, change:

<TargetFramework>net46</TargetFramework>

to

<TargetFrameworks>netstandard2.0;net46</TargetFrameworks>

More info: Immo Landwerth has a great video from yesterday's dotnetconf event here. At ~ minute 23 into the video, he says there are problems/bugs with .NET 4.6.1 consuming .Net Standard 2.0 libraries. He recommends using .Net 4.7.2 (has to be downloaded separately), but turns out that's not the issue. Instead, just need to edit the XML of the Vts project to do true multi-targeting. The WPF and console applications can then have Vts as a dependency, and there's no need for the separate Vts.Destkop project anymore. At least, that's the theory. We should create a branch and flush this out.

from vts.

Here's the SO post that helped me: https://stackoverflow.com/a/42364427/22528

from vts.

As per my reasons above we do still have a need for the Vts.Desktop project. The information you provided is very helpful for using the .NET Standard library in .NET Framework projects, thank you for the references.

Until .NET Standard and .NET core are more widely used, we feel more comfortable keeping the .NET Framework version. The code is identical now so for maintenance purposes, it doesn't create any additional work.

from vts.

My proposed change includes .NET desktop build, it just eliminates the need to keep a separate Vts.Desktop project, instead using multi-targeting so that one Vts project results in a .NET 4.6 and .NET Standard library. Could also add 'netcoreapp2.1' and build three libraries with one project.

from vts.

Added to the .NET Standard 2.0 project as a possible future enhancement.

from vts.