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).
Related
I'm getting the error.
The command:
"C:\ProjectDir\.nuget\NuGet.exe" install "packages.config"
-source "https://www.nuget.org/api/v2/"
-NonInteractive
-RequireConsent
-solutionDir "C:\ProjectDir\ "
exited with code
-1073741502 while building one of my Class Library projects in my solution.
As a result, I'm getting many
Metadata file 'C:\ProjectDir\src\ProjectName\bin\ProjectName.dll' could not be found`
errors from other projects in my solution.
When I click on restore packages for the solution it shows that there are no packages to restore.
Any idea about the fix?
While it's interesting to know that NuGet exited with an error code, it's far more interesting and useful to know what the program's output is. By not sharing that with us, we have to do a lot of guessing, reducing the chance that you get an answer that helps your specific case.
Anyway, NuGet.exe's program returns 1 for almsot all error codes (unless something throws an ExitCodeException, but it appears that only signing related code returns anything other than 1). Therefore, I conclude that NuGet didn't actually run. My best guess is that you ran on a machine without recent versions of the .NET Framework installed, but you're running a newish version of nuget.exe that needs a newer .NET Framework.
You also didn't say what version of nuget.exe you're using. NuGet 5.x is designed for Visual Studio 2019, which has a minimum requirement of the .NET Framework 4.7.2. NuGet 4.x is designed for Visual Studio 2017, which has a requirement of .NET Framwork 4.6. However, Wikipedia says that the .NET Framework was released in April 2018, which suggests to me that if you don't have that installed, you're not running Windows Update and so you're probably vulnerable to all sorts of malware. Perhaps you've just turned off recommended updates and getting only the critical updates, but it's worth checking.
So, while I expect this to be the cause of the problem, I also want to comment that it's normal to run nuget restore, not nuget install, to restore packages for projects and solutions. Also, it's typical to simply run nuget restore mysolution.sln. This has several benefits. NuGet can restore the entire solution more efficiently than one project at a time. Secondly you no longer need to provide the -SolutionDir argument.
One possibility about why you're restoring one project at a time is hinted by the fact that you're running some_path\.nuget\nuget.exe. This was done in Visual Studio 2010, VS2012 and VS2013, but was removed from VS2015 onwards. Back then it was enabled by right clicking the project and selecting "Enable NuGet restore for solution" or something like that. This was because NuGet was not really integrated with Visual Studio back then, other than adding this command which would modify all your .NET project files and create the .nuget/ directory with 3 files. Since then NuGet is integrated with Visual Studio and can do automatic restores without hacking project files, so it's no longer needed. NuGet has docs on migrating to automatic package restore.
The only advantage of the old package restore that changes the .NET project files is that on a CI machine there's nothing extra to do. Simple clone the repo and run msbuild. Once it's removed, it's necessary to run nuget restore on the solution file before building, to restore packages.config projects. If you can migrate to PackageReference (needs Visual Studio 2017 or later), then the NuGet restore step isn't necessary, you can run msbuild /restore mysoltuion.sln, or if all projects in the solution are SDK style, just dotnet build. Although some people still prefer to separate restore and build into separate steps, so when there's a failure, it's more obvious if it was a restore or compile error.
Recently installed Visual Studio 2017.
Usually, when you create a new project, you immediately fire it up and run the scaffolded code.
Unfortunately for me, the new project doesn't have the required packages making the build fail.
Also, objects in the code are marked as not recognized. This is also correct for javascript dependencies.
4 new projects of different types, same result. Didn't even change the code yet I can't build.
The light bulb icon doesn't even show the dependency. Visual Studio doesn't recognize it.
How come scaffolded code has missing references??
Please help.
Well, this was annoying...
Package restore was disabled.
Enabled it in Visual Studio's options and ran the project.
Packages appeared magically.
Tools > Nuget Package Manager > Package Manager Settings
I get this error when using SQLite.
DllNotFoundException: Unable to load DLL 'SQLite.Interop.dll': The
specified module could not be found. (Exception from HRESULT:
0x8007007E)
I tried several solution without success.
Tried using x86/x64
Tried this:
Visual Studio 2017 Xamarin UWP break, unable to load "sqlite3"
Added 2015 Visual C++ runtime dependency for UWP.
Tried manually adding the .dll and set it to "copy always".
Tried installing locally depedencies from here
I'm really out of ideas.
I had this problem running in release but not in debug.
I am using VS2017 15.9.5
Using Release manager I changed all the projects to use Release x64
Strangely the Platform tab asked me to make a new Platform and I had to do this in order to be able to pick an x64 platform
I wound up installing the SQLite modules in all the projects, not just the data tier. it would not work with just the data tier, even though I had Copy local true.
Here are the nuget packages I used
I am trying to publish my Web App in Visual Studio Professional 2013 but getting the following error
I got the same question asked over here but no useful answer.
Can anyone please help
You probably will be using older version, that was having an issue. refer detail [here]
Install the newer web deployment tool, should work.
which .net version are you using.
check web deploy version. if vs has 2 web deploy version, the vs get confuse to take which version. If it has 2 version, just uninstall vs and then instal it along with web deploy. if the Vs has one 1 web deploy version, you uninstall and install the web deploy. It will rectify your problem i hope.
You can refer This link
Check if version 9.0.0.0 of the assembly is installed in GAC. (from the VS2013 developer command prompt) gacutil /l Microsoft.Web.Deployment. Issues like this have occurred in the past where things worked, then after installing an update (or trying to install one) then reports of missing dlls, like nuget, occur.
The usual course of action is to repair the Visual Studio installation.
There is a problem with your publish profile. Delete the pubxml file located bellow Properties folder in your project and then create a new publish profile.
I got the same problem when older project runs into the new .NET Framework, for that you have to do the following.
Right Click on your project name->select Property Pages -> Click Build from the menu-> then select Target Framework .Net framework 4.5 or your current using framework..
"Could not load file or assembly" means the required file (of that mentioned version) is not available in the assembly (nor in the registry). All you gotta to do is to ensure this same is installed properly that would allow you to proceed further. The other things to ensure is the latest framework installed on your system.
Think you have some errors happen when to install or update Visual 2013, so you can reinstall again and this error will be fixed.
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.