I have been encountering several of these warnings after upgrading from .NET 4.5.2 to 4.6.1
3>C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5):
Warning MSB3274: The primary reference
"[...]AbcManagement.Commons.dll" could not be resolved because it was
built against the ".NETFramework,Version=v4.6.1" framework. This is a
higher version than the currently targeted framework
".NETFramework,Version=v4.5.2".
I have checked all referenced projects. All of them target Framework 4.6.1 now. The Solutions Builds without Errors or Warnings and it also runs localy. Only when I try to publish the solution using: right click on project -> publish, it starts the publish and exists with an error, which is related to this warning.
I have read on similar threads, to make sure to have installed the correct Framework on the local machine. This also led to no satisfying result.
What am I missing?
I ended up creating a new project, add my .cs files into the new Project and reinstall all NuGet Packages. This finally solved the problem.
After setting up the new project, I compared the configuration files but couldn't find differences in the configurations which would affect this issue. Unfortunately, therefore I can't point out the exact change made to make the publish work in a completely new project.
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.
I create a new project using VS2017, select new Console App (Core) version 2.1; etc. When I use NuGet to install the Entity Framewwork Core, version 2.1.1, it is not installing to the Assemblies directory but instead appears under the NuGet directory. When I try to add a migration using the package manager I get a 'The term 'add-migration' is not recognized' error. I have reviewed the other SO answers to this problem, and searched google, but none of those helped.
I have another project, it's an older one from several months ago, where the Entity Framework Core was installed under the Assemblies directory and for that project everything seems to work.
From the above it appears that where NuGet places the Entity Framework Core dll is the only difference and it is causing the package manager to fail to find it.
The get-module command for the older project shows the Entity Framework Core and the correct version, but get-module for the new project does not.
Any thoughts on why this is happening and how I can fix it?
From this post :
The solution that worked for me after trying a whole raft of other solutions posted, was to right click on my project => select 'Manage Nuget Packages' => select the browse tab, but thick 'Include prerelease' check box, and install the 'Microsoft.EntityFrameworkCore.Tools'. N.b that aspnetcore project in visual studio 2017 do not seem to have the 'project.json' file.
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'm getting a curious error when attempting to generate a view via the 'Add View' dialog. Simply leaving the dialog as is (ie creating view 'View') and hitting 'Add' yields the following error dialog:
Error: There was an error running the selected code generator: 'The Templates/PackageVersions5.0.1xml file is missing from the installed template folder.'
Which I'm afraid means little to me. I've googled the xml file to no avail.
Not really sure where to go now - I'm unable to add views to my project via scaffolding (though I can of course just by 'adding a new item' and building it myself).
How can I track down the source of this error?
Posting here because I ran into the same "file is missing" issue with Visual Studio 2019 and PackageVersions5.2.6.xml. This was one of the only pages I could find related to this scaffolding issue so I suspect others will find their way here too.
I found that upgrading the "Microsoft.AspNet.Mvc" package via NuGet to 5.2.7 was not sufficient to fix the problem. I also had to upgrade "Microsoft.AspNet.WebApi" and its related packages to 5.2.7. The Add View option started working again afterward.
Just make sure you have same version of MVC nugget in all projects, if you only have one project then upgrade/downgrade MVC to different version then revert back to the version you require and issue will get fixed.
I just changed version from 5.2.3 back to 5.2.2 and then reverted back to 5.2.3 and all worked. It appears some file got messed up or and then was restored by this.
I got same issue while using visual studio 2019 community edition, where I am able to create view using visual studio 2017.
After reading answers here, I tried upgrading Microsoft.AspNet.Mvc package, and it works for me.
I'm afraid the rather unsatisfactory solution I arrived at was to create a clean project and import the project elements in, recreating the project from scratch.
I assume that some deep-configuration had become corrupted and I was unable to work out how to fix it.
I ran into the same problem when using a project from VS2013 in VS2015. In my case it was PackageVersions5.1.3.xml that was missing. 5.1.3 seems to be the version of MVC this project was using. I updated MVC to the latest (currently 5.2.3) and this solved the issue.
The XML file should exist in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web\Mvc\Scaffolding\Templates\
I had the same issue. The problem started after installing DevExpress to project. I found that DevExpress installation creates some DevExpress folders in D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions but all necessary files for scaffolding lived in D:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions. I copied the content of extension folder from vs professional to enterprise restart Visual Studio and Scaffolding works again.
I have downloaded published (code behind files are no there, combined with dll in bin folder) web application from Window Server 2008 where it is hosted, and open it with Visual Studio when I debug that application it shows following error:
"Could not load assembly because this assembly is built by a runtime newer than the currently loaded runtime"
I don't know how can I solve this problem and test application locally.
Please help me.
This errors happens when the DotNet framework you are using is of older version than the one used to build the assembly. You need to check which version of framework is used to build those assemblies and then use the same or higher to debug too.
I was getting this same error when running an installer for a Windows service, even when running the installer on the PC the installer was built on.
It turned out that although the Windows service project had been updated to .NET 4.5, the Setup project that was making the installer was still set to use .NET 2.0.
To check if the Setup project is using an older version of .NET than the project to be installed, in the Visual Studio Solution Explorer:
Expand the Setup project;
Under the Setup project, expand Detected Dependencies;
Under Detected Dependencies select Microsoft .NET Framework and check the Version property. Select the appropriate .NET version from the dropdown list;
Re-build the Setup project to create a new version of the installer.
This error can have a lot of other reasons, too. I had the same problem, and nothing helped until I stumbled across this:
TlbExp.exe error:This assembly is built by a runtime newer
I just ran into this issue when the assembly was built with a target framework of .NET 4, and v4.0.30319 was installed on the server, and other 4.0 apps were running successfully.
The problem arose because the app had originally been built targeting 2.0, and new 4.0 assemblies were pushed, but not the app.config file, which we generally update separately.
This means the supportedRuntime attribute was not updated in the config and caused the error. Adding the following to the app.config fixed our issue:
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
One the the assemblies reference in the project might be built using a newer version of .net, check version of every assembly reference and correct accordingly.
Also check the application pool that this web site is running as. It could be framework 2.0 default on some older windows servers. Change it to framework 4.0.