Home: Creating unit test project using .NET Framework template will open older project model with packages.config

[davkean]

_From @eriawan on March 26, 2018 6:48_

Hi guys,

Now that most of us use VS 2017 15.5.x or later, the project creation (including .NET Core and .NET Framework new project creation) should by default choose PackageReference model.

Machine configurations: (I have 2 machines)

• OS: Windows 10 Pro, build 16299.15
• VS used: VS 2017 Enterprise 15.5.5, VS 2017 Enterprise 15.6.4
• No VS 2017 preview installed

Problem

Every time I create unit test project using .NET Framework template will open older project model with older packages.config model, even though I have set up the Package Management settings to always use Package Management as the default.

Current workaround

I have a temporary workaround, by updating the unit test csproj to use ordinary class library (but still use newer PackageReference) and let VS 2017 explore the unit test nicely, then it will be built nicely by MSBUILD. The normal dotnet restore afaik won't restore the nuget packages used in .NET Framework class library csproj that uses MSTest unit test. But I can use MSBUILD /r to restore nuget packages in projects in my solution as long as I'm sure that I use PackageReference on all of my projects inside the solution.

Questions and suggestions

1. Is this the default behavior? Because if I use the legacy project model, I have to run nuget.exe restore before compile using MSBUILD every time I run CI especially on VSTS/TFS.
2. If this is the default behavior, then the legacy project model of .NET Framework unit test should be updated to use PackageReference as the default package management settings on VS 2017. There might be some problems about the GUID of the project type, and I also suggest to add new GUID as the unit test type project that uses PackageReference model. As far as I know by looking at current master branch, I can't find any references for this. CMIIW, though.

_Copied from original issue: dotnet/project-system#3421_

[jainaashish]

We're actively working on moving the whole NuGet ecosystem from packages.config (PC) to PackageReference (PR) but that hasn't been the smooth ride. There are still lot of packages out there which don't work well with PR. So we're being little cautious there while we either move existing solutions from PC to PR, or default new projects into PR.

This dialog is a step in that direction to move people, but at the same time doesn't come into effect until you actually try to install a package into newly created project. So if you changed the default there, that will only come into effect when you actually install a package. For your scenario, you can set this MSBuild property <RestoreProjectStyle>PackageReference</RestoreProjectStyle> into .csproj file which will make this project as new style even without installing a package.

Now, lastly we do want everyone to move from PC to PR and foresee a time when default project creation faults into PR but I can't give you a exact time frame or dates when that'll happen.

[eriawan]

@jainaashish
This is me, eriawan. I'm the original poster of this issue, previously posted on dotnet/project-system.

Pardon, what I'm trying to say is the unit test project creation that target .NET Framework is always having older packages.config model.

If I create an ordinary class library project that has the MSTest nuget packages imported, I'll be fine in VS 2017 15.5.x or later, thanks to automatic unit test discovery done by VS. I also have reproduced this workaround this many times.

So, put it simply, why don't we just add new project template for unit test that target .NET Framework but without the legacy import targets and the dual GUID?

@davkean imho if we can create new project template with .NET Framework 4..5.x/4.6.x/4.7.x that simply a class library with added MSTest v2 nuget packages embedded as , this should be a good fix too, because as far as I know we're moving more to model.
This is why I originally posted on dotnet/project-system, also to propose a simple new template that avoid the problems of packages.config and superfluous imports in the legacy unit test project 🙂

[eriawan]

Any update on this issue?

@jainaashish my issue is quite unrelated to your last comment. It's about the default template used by MS Test unit test for .NET Framework that always use legacy csproj unit test model with packages.config used.

IMHO as described in my workaround in the issue, it should use the newer csproj model, or we can simply use latest .NET Framework class library project that already use <PackageReference> model. I have use this workaround for creating new .NET Framework-based MSTest unit test projects, and VS 2017 could find it and then display them in the Test Explorer. Therefore, it's not related to migration from PC to PR project model.

cc @rrelyea

[jainaashish]

@eriawan thanks for clarifying your issue. You originally posted this issue at the right place, but @davkean might have also misunderstood like me. So I'll move it back there, it should either be project system or unit test team call to update their templates.

[eriawan]

@jainaashish
Thanks! I think you're right, @davkean might have misunderstood me.

@davkean
Could you reopen my previous issue on dotnet/project-system#3421 now? I think my previous issue posted on dotnet/project-system still holds valid, therefore I believe it's not actually Nuget issue.
Please confirm.

[jmarolf]

@jainaashish this is not a project system bug. This is an issue with the nuget template wizard.

Steps to Reproduce:

1. User sets default package management format to be PackageReferences
   

2. User creates a project (for example: .NET Framework test project) that has the following usage of the nuget template wizard in its vstemplate file

  <WizardExtension>
    <Assembly>NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
    <FullClassName>NuGet.VisualStudio.TemplateWizard</FullClassName>
  </WizardExtension>
  <WizardData>
    <packages repository="extension" repositoryId="mstestProjectTemplate" isPreunzipped="false" >
      <package id="MSTest.TestAdapter" version="1.2.0" skipAssemblyReferences="false"  />
      <package id="MSTest.TestFramework" version="1.2.0" skipAssemblyReferences="false" />
    </packages>
  </WizardData>

Expected Behavior:
Project is created with PackageReferences

Actual Behavior:
packages.config is used

[jmarolf]

Sorry for cross posting from different threads but as I already posted this here.

And that's the reason, this has to come from individual templates owners when they know they supports PackageReference, then they can either set a msbuild property RestoreProjectStyle in their template or directly add PackageReference whatever is convenient for them to do.

@jainaashish what should the XML below be so that we opt-in to whatever the user has set as their default package management format?

  <WizardExtension>
    <Assembly>NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
    <FullClassName>NuGet.VisualStudio.TemplateWizard</FullClassName>
  </WizardExtension>
  <WizardData>
    <packages repository="extension" repositoryId="mstestProjectTemplate" isPreunzipped="false" >
      <package id="MSTest.TestAdapter" version="1.2.0" skipAssemblyReferences="false"  />
      <package id="MSTest.TestFramework" version="1.2.0" skipAssemblyReferences="false" />
    </packages>
  </WizardData>

[eriawan]

@jainaashish
Let's continue the discussion here then.

How to know more information about the project template wizard you mentioned in your comments in dotnet/project-system/issues/3421#issuecomment-378337134 ?

Is this project template wizard opensource?
Ok, I have found the source: https://github.com/Nuget/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.VisualStudio.Interop/TemplateWizard.cs

[jainaashish]

I'm not sure how to specify msbuild property in vstemplate file? msbuild or vs extension team might knows anything. @jeffkl

[jainaashish]

and if there is no way to specify msbuild property with vstemplate file then NuGet should provide an additional parameter on packages tag to specify.

[jeffkl]

You could place the MSBuild property in the project during creation but I would not recommend that. The code that is adding the packages to the created project is probably just not respecting the user setting of default package style. In my opinion, the code that adds the packages should be looked at.

https://github.com/NuGet/NuGet.Client/blob/7985322db49b11340ad4bf0c73247c9bd0096621/src/NuGet.Clients/NuGet.VisualStudio.Implementation/VsTemplateWizard.cs#L269

[eriawan]

@jeffkl
Thanks and this is great update! I think we could add the PackageReference setting check.

Imho, looks like the fix to add setting check should be quite straightforward.

[eriawan]

@jainaashish

Any news/updates on this issue? It's been 5 days without any updates.
Please let me know, at least the progress or the decision made on this issue.

It is definitely a bug, and it's always reproducible.

[nkolev92]

@eriawan
This is an old gap, and we will look into it soon.

Please note that this is not the only issue we have on our radar, we will update the thread as soon as we have more information.

[nkolev92]

This is related to https://github.com/NuGet/Home/issues/4693

In PackageReference, the local repository cannot be used as a source because it breaks repeatability.

[eriawan]

@nkolev92

This is not related to #4633, it is about inconsistencies in resulting project template when VS 2017 is using PackageReference by default for .NET Framework unit test project.

[jainaashish]

@eriawan I agree, it not exactly dupe of #4633 but scenarios are somehow related.

Coming to this issue, those TemplateWizard APIs were never made compatible with PackageReference which is why @nkolev92 said as a old gap and not being a regression. This scenario has never worked.

Now, we're investigating and analyzing what could the best approach here going forward. This isn't straightforward as it looks. Because what happens when User set his package style to PackageReference but underline project doesn't support PackageReference yet or have some major concerns with it. There are projects like C++, web application, JS, etc... which are still not fully compatible with PackageReference. So we're talking our time to come up with right solution to come up with combined approach of project templates by default faulting into PackageReference and allowing users to choose their package style as well for supported projects.

[eriawan]

@jainaashish

For unit test projects that target .NET Framework, is the template is generated on the fly? If it's generated, where is the code that check the PackageReference setting and generate the project template for unit test projects that target .NET Framework?

I really want to know, and I also eager to contribute a fix or additional feature for this.

Afaik, if current Nuget Package Management setting is set to use PackageReference, we can simply have a class library project but it adds MSTest V2 nuget packages. Just like I have proposed originally.

Have you tried this class library project that has MSTest V2 nuget packages that contains unit test codes? Again, it works on my machine using VS 2017 15.4.x or later, because the unit test codes can be discovered by VS automatically.

[nkolev92]

@eriawan

The template is generated, but the packages are installed on the fly.

I have already a working fix I did as a POC that this could be done reliable (i.e. avoid using PR for project types that simply won't work), but there's a bit more work left.
If you're curious take a look at my branch dev-nkolev92-prtemplate.

We're considering the whole scenario, but we'll for sure have an improved behavior in the 15.8 timeline.

[eriawan]

@nkolev92

The template is generated, but the packages are installed on the fly.

Which packages? Do you mean the MSTest nuget packages? Or other kind of packages?

So the fix is scheduled for 15.8, not 15.7 timeframe?

[nkolev92]

@eriawan

Which packages? Do you mean the MSTest nuget packages? Or other kind of packages?

The test packages yes or any packages that the template might be installing, as this impacts other templates as well.

So the fix is scheduled for 15.8, not 15.7 timeframe?

I can't commit to which fixes actually make it to 15.8, but it's very likely.
It's too risky to consider it in the 15.7 timeframe.

[eriawan]

@nkolev92

Any progress on this fixing this issue? Or could I also try to test your unit test project POC work?
I'm willing to help as much as I can on this issue.