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
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.
Related
When I create a clickonce deploy of a wpf application many microsft dll's are missing in the deployment.
f.e. system.dll, system.data.dll, system.reactive.core.dll, system.xaml.dll, ...
Any suggestions ?
Since you still need to install the .NET Framework on the computer on which you want to install the ClickOnce application, it doesn't make much sense to include these assemblies in the deployment. They should be available in the GAC anyway.
You can include any other assemblies - including the system.reactive.* ones - by including them under Project->Properties->Publish->Application Files... in Visual Studio before you publish.
If you set the Copy Local property of these assembluies to True in the Solution Explorer, they should be included by default.
Note that if these assemblies are referenced from another project than the one you publish, you should copy the references to the WPF application project that you publish. If they are part of a NuGet package you should also add that NuGet package to the project being published.
I am getting the following exception while referencing a .Net standard 2.0 project from WPF application developed using .Net framework 4.6.1 project
Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.'
Any suggestions?
As of today (using VisualStudio 2017 15.8.4) this still seems to be a common problem:
Transitive dependencies are not correctly handled with the package management format which uses the packages.config file to reference dependencies.
The problem is that VisualStudio 2017 still uses this old package management format by default when you create a new WPF desktop project.
Solution
The solution is to migrate the project references from packages.config file to the new PackageReference node in the .csproj project file.
VisualStudio can do this migration automatically for you. The migration is documented here:
https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference
Please note that there is a known issue:
The Migrate packages.config to PackageReference... option is not available in the right-click context menu until NuGetwas initialized.
Another option if your project does not have any package references at all is to change the setting of RestoreProjectStyle to PackageReference in your .csproj file.
https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#using-packagereference-for-a-project-with-no-packagereferences
I hope this helps.
Add reference to Microsoft.EntityFrameworkCore package in your WPF project.
Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?
Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.
Reproducing it is extremely simple. I'm using VS2015 Community.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
Why? And how to fix it?
Update
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.
Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.
For more information see:
http://www.github.com/iswix-llc/iswix-tutorials
I am authoring a management pack with custom views using Silverlight / WPF (shared code) and MP authoring console and MP authoring tool in Visual Studio.
I am following this tutorial on custom views.
Widget for SCOM operation and web console - custom
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
I cannot add references to the Silverlight project. I get an error message:
Is there any way to get around this?
I understand that the .net runtime is different than that of Silverlight. Yet, this tutorial shows a working example, so it there a missing step or a different binary. What am I missing?
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
The important bit is the bit in bold, you need to download the sample project and copy the references from there. Were you doing this?
http://gallery.technet.microsoft.com/Creating-a-Widget-for-104711ac
If you download this zip and go to the following sub directory
\Creating a Widget for Operations Manager Dashboard - Walkthrough %231.zip\Creating a Widget for Operations Manager Dashboard - Walkthrough #1\Section_4\AlertSummarySilverlight\Bin\Debug
You'll see the two assemblies in this folder. Copying them out of the zip into another folder and add a reference to them. This works for me in Silverlight 5.
I want to create a Visual Studio 2010 setup project that deploys some files to a folder where my application can use it from. I want it so, that all users have the same files, and that they also could manipulate them without admin rights.
Thus, "Common Application Data Folder"* as described in this MSDN article, seems fine.
However, in my Visual Studio 2010 setup project I did not find the "Common Application Data Folder" available in the "Add special Folder..." drop down menu.
I have a .NET 4.0 WinForms app and see no reason why this does not show up.
The user's common application data folder is available but does not match my intended use.
Thanks for any hints!
Visual Studio setup projects do not have a predefined folder for common Application Data. However, you can install files in it like this:
add a custom folder and select it
in its Properties pane set DefaultLocation to:
[CommonAppDataFolder]
in this folder add the files you want installed in common Application Data
During install CommonAppDataFolder will be automatically resolved by Windows Installer.
A more specific solution might be to set the DefaultLocation property to:
[CommonAppDataFolder][Manufacturer]\[ProductName]
Manufacturer and ProductName will be resolved from the values you assign to the corresponding properties of the setup project.