I have a private Nuget server, and I need to use some of my libraries in my Visual Studio Extension that I am writing. While debugging, the VSIX works fine. But once other developers try to install my extension, the installer can't find some of the nuget packages because it is only looking at nuget.org and not my private server. So my question is, how can I configure my VSIX to include my private server when pulling the nuget packages while installing itself on other developer's machines?
Thanks! :)
Related
Visual studio shows no update button to update the Nuget package manager, but when i try to install Microsoft.EntityFrameworkCore.SqlServer i'm getting a error saying update the nuget manager by going to particular website (https://www.nuget.org/downloads)
Upgradation of VS12 nuget package manager is not possible now!
If you want any packages that is compatible with VS2012, while installing any packages you check with versions of that particular package version in nuget official website (supported for VS12) by clicking on the version tab.
You already have the most recent version of NuGet that is available for Visual Studio 2012. VS2012 is very old (in software terms) and hasn't has feature upgrades in a long time. You'll need to upgrade to a newer version of Visual Studio for some NuGet features to work (for example, to be compatible with packages that use features only available in newer versions of NuGet). Alternatively, you might have luck with Entity Framework 6, rather than Entity Framework Core. However, there's a chance that even then you'll need to install an older version of EF6, rather than the newest version, to find a version that is compatible with VS2012.
We use our own Azure Artifacts instance to provide a private Nuget feed. It has a default setup, with the #Local view as the default view.
After updating a project on one of the developer machines from dotnet core 3.x to 5.0 all went fine on the dev machine. But then other developers started getting problems with restoring packages.
These developers tried dotnet nuget locals all -c then dotnet clean && dotnet restore after making sure they have the correct SDK installed (5.0). But the Azure Artifacts server cannot provide the correct package version, specifically;
error NU1102: Unable to find package Microsoft.AspNetCore.App.Ref with version (= 5.0.0)
I am aware that this package is an "internal package" in dotnet, and I have confirmed that it is not explicitly defined as a dependency in the projects that reports errors. It is some sort of implicit dependency.
I am also aware of that Microsoft says that one must add packages to a private feed that one wants the consumers of the feed to have available.
How can I possibly add such an "internal package" to the Nuget feed, when it is not meant to be consumed explicitly?
Why cannot Microsoft query a upstream package source when the requested package is not found in the private feed? (the 5.0.0 package version actually exists on nuget!)
How come that I do not have to download such a package myself when running dotnet restore, but my peers have to? (and fails at it, even though their dev environment is similar to mine)
I am trying to build a Blazor Server project that I have cloned from a repo. I am getting the message in the Output window of Visual Studio 2019 that the Shared namespace does not exist. The Shared namespace is created in the Blazor template and was not something I added to the project. This also happens if I create a new project and try to run it. Others on my team are able to clone this repo and run it. I have uninstalled and reinstalled Visual Studio 2019 Enterprise edition and also the Dotnet 3.0.1 framework. The only thing I can think that might be the difference is that I updated my VS 2019 to 16.3.10, but even after uninstalling and reinstalling, I have the same issue. I know I have read some things about mismatching of VS and Dotnet core framework SDK versions causing issues but not sure if this is the case here.
I was able to resolve this issue by rebuilding the project after clearing Nuget Caches.
Path: Tools -> Nuget Package Manager -> General -> Clear all Nuget Cache(s).
I have a simple asp.net 5 web application.
My project.json file contains dependency:
"Microsoft.IdentityModel.Tokens": "5.0.0-rc2-301060021"
When I restore nuget packages, this package is restored well on my machine. project.json file is in source control, but it does not work on other machine. It says that this package is not found.
Anyway, in nuget configuration Im pointing to my local nuget packages repository, which does not even contain asp.net 5 nuget packages. Where all of these packages come from?
RC2 has not yet been made public, we're still on RC1. Here is the roadmap schedule, which indicates sometime this year. If you do somehow have the package on your machine, you could setup another NuGet feed that others on your project could point to -- then simply place the package in there, so it's on shared feed.
Here is some helping documentation that shows you how to do that.
I have many .sqlproj projects that need to be built on our build server. I don't want to install all of Visual Studio on the build server just so I can install SSDT to build these. How can I build .sqlproj projects without a full VS install?
Here's the raw error I get on the build server when trying to build without SSDT intstalled:
C:\MyProject\MyProj.sqlproj (4): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Answer: Microsoft now has an official NuGet package (see blog post).
Old answer, prior to August 2016; provided in case the NuGet package doesn't work for you:
Install dacframework.msi (x86|x64)
Install SQLDOM.MSI (x86|x64)
Install SQLLS.MSI (x86|x64)
Install SQLSysClrTypes.msi (x86|x64)
Install SSDTBuildUtilities.msi (from the "Administrator Install Point" as setup in step 3 here)
Done!
Source: Headless MSBuild Support for SSDT (*.sqlproj) Projects.
Microsoft SQL Server Data Tools:
http://msdn.microsoft.com/en-us/data/hh297027
Install the tools on build machine to fix the problem.
The Microsoft SQL Server Data Tools team has released a NuGet package named Microsoft.Data.Tools.Msbuild, which helps to build SQL Projects on build servers.
see : https://blogs.msdn.microsoft.com/ssdt/2016/08/22/releasing-ssdt-with-visual-studio-15-preview-4-and-introducing-ssdt-msbuild-nuget-package/
NuGet package : https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild/
SSDT v12.0.50730.0 requires Visual Studio to be installed beforehand. I found the easiest solution was to install the bare minimum Visual Studio components which were downloaded from MSDN Subscriber downloads:
Visual Studio 2013 Isolated
Visual Studio 2013 Shell
Then SSDT installed fine.
I also used part of the solution outlined above.
* Install dacframework.msi
* Install SQLDOM.MSI
* Install SQLLS.MSI
* Install SQLSysClrTypes.msi
I use MSBuild 12.0 to perform the build which is also available as a separate download.
I was having the exact same issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me.
Some answers mention a NuGet package, but I am not sure how can I use it, because SQL Server projects do not allow to install NuGet packages.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation about my implementation in this answer.