Package tab missing from project properties

Question

Attempting to create nuget package to upload to our own nuget sever, and would like to eliminate the manual process of creating and editing the nugspec file. Everything I've read, says the setting can be pulled from the project file (if using package reference). And that the settings exist on the Package tab of the project properties window. But that tab is not there.

Using vs 2019, .NetFramework 4.7.2, project is a library, and has been migrated to package reference. I took an existing project, right clicked the references, and used the migrate option. Package tab is non-existent

I also set the nuget package manager to default to packageReference, and create a new class library. Package tab also non-existent

The required package (when using non-SDK Style with package reference) nuget.build.tasks.pack has bee added to the references of both projects mentions

Any help would be appreciated

Answer 1

The package tab is only available for SDK style projects. Non-SDK style projects use a different project system in Visual Studio, which doesn't contain that project properties tab. The new project system (on github, the old one is closed source) was initially made to look the same as the old project system, but slowly they're diverging. The Reference/Dependencies node in Solution Explorer is one obvious example, as is the Package tab in the project properties window.

To create the MSBuild properties used by pack, you'll need to manually edit the project file as XML. Within Visual Studio, you need to right click the project in Solution Explorer, select "unload project", now when you single click the project, or right click and select edit, you'll see the project XML. Once done, right click the project again and select reload project. Alternatively, edit it with a text or XML editor outside of Visual Studio, and Visual Studio will detect the change and prompt you to reload the project when you alt-tab back.

My suggestion, however, is to convert your non-SDK style project to an SDK style project. "Standard" class library projects work fine, and I'm not aware of any disadvantages (unless some developers on your team are using Visual Studio 2015 or earlier still), given the non-SDK style project is already using PackageReference. Some other project types might have limited Visual Studio experiences when targeting .NET Framework in an SDK style project. Other project types might not be compatible with SDK style projects at all. However, most people creating NuGet packages are doing so with standard class library projects, which shouldn't have any problems.

There is a "unsupported" tool try-convert to convert non-SDK style projects to SDK style. Personally, I just delete the csproj, create an empty directory, run dotnet new classlib on the console, move the csproj to my existing project's directory, rename the project file, and delete that temporary/empty directory. If you have anything other than .cs files in your project that need explicit entries in the csproj, hand edit the csproj if you're comfortable with msbuild, otherwise load the project in Visual Studio and use the Solution Explorer and Properties windows.

Some people believe that SDK style projects are only for .NET Core or .NET Standard. That's not true, but unfortunately the Visual Studio new project templates give that impression. You will need to create the class library project targeting .NET 5, .NET Standard, or .NET Core. But once the csproj is created, edit the csproj (with SDK style projects it's no longer necessary to unload the project) and change <TargetFramework>net5.0</TargetFramework> to <TargetFramework>net472</TargetFramework>. Another advantage of SDK style projects is it's easy to multi-target, a useful technique to slowly modernize your projects to newer runtimes. Add an s to the XML element name to make it plural, and add extra target frameworks as a semi-colon delimited list <TargetFrameworks>net472;net5.0</TargetFrameworks>. When changing between TargetFramework and TargetFrameworks, Visual Studio should prompt you to reload the project, but I found that it still has some issues. So I suggest closing the solution and opening it again, then everything should work great.