No matter what I do my .net Project will always rebuild. I read this Article https://oz-code.com/blog/visual-studio-keeps-rebuilding-projects-no-good-reason/, and I found the CopyLocal problem in my Project.
I got this message: Project 'PROJECTNAME' is not up to date. CopyLocal reference 'D:\...PROJECTPATH...\bin\x64\Debug\System.Net.Http.dll' is missing from output location..
My System.Net.Http.dll is referenced like this (Don't ask me why Private is set twice):
Visual Studio itself shows me it is taken from the "Reference Assemblies":
And as I figured out, Assemblies taken from the "Reference Assemblies" are never copied to the output folder.
Now the problem, if I change the CopyLocal to false it works, but after any NuGet restore it will be set to True again. I assume this is caused by the fact that the HintPath is refereing to a NuGet package where CopyLocal should be set to True.
It only happens with "System.*" references. The Project is .net 4.8 and I'm using the latest VS2019.
Is there any way to prevent this, or did i miss something how I can fix this? This is happening in a quite big solution and it takes forever to build if everything is rebuilt all the time.
I tried ReSharper-Build, and that worked but if possible i would like to stick to the standard.
Thank you for any help.
Is there any way to prevent this, or did i miss something how I can
fix this? This is happening in a quite big solution and it takes
forever to build if everything is rebuilt all the time.
As Hans said, you reference two system.net.http.dll in the same project in different ways so that it creates a build mess, making it impossible to determine the version of the reference. And it turns always rebuild.
In fact, System.Net.Http.dll is just a part of Net Framework4.8 and exists in the Reference assemblies.
All of this points to the fact that this is a public,global DLL that can be used directly in VS without having to install it using nuget. So I'm curious why you're still using nuget to install it.
Note: When you create a new net frameowrk4.8 project and then open reference, and you will find that it already references system.net.http.dll from Reference assemblies. So when you use nuget to install it or use the path of the nuget in the HintPath, it will not change the inital path.
Solution
To solve it, please uninstall the nuget package System.Net.Http.Right-click on the project-->Manage Nuget Packages--> uninstall it.
Hope it could help you.
The following line gives an error saying it doesn't exist in the current content.
Interaction.InputBox("Enter Version", "", "default");
I read other questions about this I did every possible way;
Added reference to Microsoft.VisualBasic from project add section, also included;
using Microsoft.VisualBasic;
I don't understand why it creates problem.
Probably you've got an old version of the Microsoft.VisualBasic.dll.
Click on Dependencies > Frameworks > Microsoft.NETCore.App > Microsoft.VisualBasic.
Then look in the Properties window.
There you should see ..\net5.0\Microsoft.VisualBasic.dll.
If you see ..\netcoreapp3.1\Microsoft.VisualBasic.dll - that's too old.
To get the new Microsoft.VisualBasic.dll you have to base your App on .NET 5.0.
I have the same error as yours. I solved it by adding Microsoft.VisualBasic reference through Nuget package tool instead of by myself.
Propably the dll version in our system is too old, and Nuget can install the correct one.
I´m developing a visual studio extension, but unfortally I can´t check the project kind , please look de follow code:
if (project.Kind == EnvDTE80.ProjectKinds.vsProjectKindSolutionFolder)
{
list.AddRange(GetSolutionFolderProjects(project));
}
else
{
list.Add(project);
}
The common advice found online is to set "Embed Interop Types" to false for the EnvDTE80 reference to false. This however, doesn't work for me. I'm not sure whether this is new for VS 2017.
I found this MSDN page which helped me: https://blogs.msdn.microsoft.com/mshneer/2009/12/07/vs-2010-compiler-error-interop-type-xxx-cannot-be-embedded-use-the-applicable-interface-instead/
Basically,
find the definition of ProjectKinds (which you can do by right
clicking and choosing "Go to Definition")
make a copy of ProjectKinds with a different name (ie. EnvDteProjectKinds) in your project
Use EnvDteProjectKinds in your project where you would have used ProjectKinds
Visual Studio 2017 version 15.8 made it possible to use the PackageReference syntax to reference NuGet packages in Visual Studio Extensibility (VSIX) projects. This makes it much simpler to reason about NuGet packages and opens the door for having a complete meta package containing the entire VSSDK.
Installing below NuGet package will solve the EmbedInteropTypes Issue.
Install-Package Microsoft.VisualStudio.SDK.EmbedInteropTypes
I'm trying to use DataAnnotations in my WPF project to specify a maximum length of strings, with the following:
using System.ComponentModel.DataAnnotations;
However, I get the error
The type or namespace name 'DataAnnotations' does not exist in the
namespace 'System.ComponentModel' (are you missing an assembly
reference?)
I've seen other examples where DataAnnotations does exist in this namespace. I'm using C#4. Is there any reason why I can't use this? What can I do to fix it?
You have to reference the assembly in which this namespace is defined (it is not referenced by default in the visual studio templates). Open your reference manager and add a reference to the System.ComponentModel.DataAnnotations assembly (Solution explorer -> Add reference -> Select .Net tab -> select System.ComponentModel.DataAnnotations from the list)
If using .NET Core or .NET Standard
use:
Manage NuGet Packages..
instead of:
Add Reference...
To Reference System.ComponentModel.DataAnnotations
In a code file to have Using System.ComponentModel.DataAnnotations; at the top of the file such as:
using System.ComponentModel.DataAnnotations;
Add a .NET reference to your project by right clicking the project in solution explorer:
Hope this helps! This question helped me.
If you don't have it in references (like I did not) you can also add the NuGet System.ComponentModel.Annotations to get the assemblies and resolve the errors. (Adding it here as this answer still top of Google for the error)
I also had the same problem and I resolved by adding the reference in one of my projects which didn't had the mentioned reference. If you have 2-3 projects in your solution, then check by adding this reference to the other projects.
I found that I cannot reference System.ComponentModel.DataAnnotations from Silverlight 5 with the below version at (1). I found that Silverlight 5 assemblies cannot use .NET assemblies, it gives the error "You can't add a reference to System.ComponentModel.DataAnnotations as it was not built against the Silverlight runtime. ..." I plan to workaround this by hopefully installing the Silverlight 5 package found at (2) below. If this fails I will update this post.
[UPDATE: it failed. I installed everything relating to Silverlight 5 and I don't have the Silverlight version of the .dll assembly System.ComponentModel.DataAnnotations . Too bad. UPDATE II: I found an old .dll having this name from a previous installation of Silverlight developer's kit for Visual Studio 2008 or 2010. I added this file and it seems to 'work', in that IntelliSense is now recognizing attributes on class members, such as [Display(Name = "My Property Name")]. Whether or not this works for everything else in this .dll I don't know.]
(1)
Microsoft Visual Studio Professional 2013
Version 12.0.21005.1 REL
Microsoft .NET Framework
Version 4.5.51641
Installed Version: Professional
(2)
http://go.microsoft.com/fwlink/?LinkId=229318
I searched for help on this topic as I came across the same issue.
Although the following may not be the Answer to the question asked originally in 2012 it may be a solution for those who come across this thread.
A way to solve this is to check where your project is within the solution. It turns out for my instance (I was trying to install a NuGet package but it wouldn't and the listed error came up) that my project file was not included within the solution directory although showing in the solution explorer. I deleted the project from the directory out of scope and re-added the project but this time within the correct location.
Use the FrameWork version 4.5 and above for your project then problem solved.Because this namespace is under 4.5 and above.
System.ComponentModel.DataAnnotations is contained in its own assembly so you need to make sure you have it refernced. Just simply:
1). Right click on Soloution and choose add.
2). Choose reference from the list.
3). Search " System.ComponentModel.DataAnnotation " and tick the check box on its left hand side and press ok.
Job done, shouldnt have any refernce errors.
If you tried to update visual studio from vs2008 to vs2010. And your app uses framework 3.5 (and you don't want to upgrade it), and also used WCF RIA Services BETA... I have bad news... you MUST upgrade to WCF RIA Services v1 (BETA does not work on vs2010)... and due to this... you also have to install Silverlight 4 + upgrade to framework 4.0
See this:
http://blog.nappisite.com/2010/05/updating-visual-studio-2008net-35-ria.html
I upgraded from Silverlight 4 to Silverlight 5 and then I was having this issue. Although I had a reference to "System.ComponentModel.DataAnnotations" under "References" in my project, it had a yellow yield sign by it that indicated the previously referenced assembly could not be found. It turned out that the properties of the "System.ComponentModel.DataAnnotations" reference indicated "Specific Version = True", when I changed this to "Specific Version = False" it fixed the issue. Right click on the "System.ComponentModel.DataAnnotations" assembly under "References" and select "Properties" from the context menu. Check that the property value for "Specific Version = False".
It must have been referencing the old Silverlight 4 assembly which was no longer available after the upgrade to Silverlight 5.
I also have this problem.
That is very stupid when i add a namespace the same with System. I try to remove all references, but it is not resolved. I use "global::System.ComponentModel", it is working as well.
When i remove my namespace, this problem has been resolved.
For .Net Core in Visual Studio 2019 try this.
see VS suggestion
It worked for me, hope it'll work for you as well.
I was moving from .Net Framework 4.7.2 to .Net Standard 2.0.
In my case, I had to change DataAnnotations's reference from an Assembly reference to a Nuget package.
This error occurs when the reference to the "System.dll" got removed.Solution to the problem is very simple add the reference to "System.dll".The dll is normally available in the following location
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727" .Add the reference your problem will get solved .
There was a problem using System.ComponentModel.DataAnnotation in net40 so I just did:
#if !NET40
using System.ComponentModel.DataAnnotations;
#endif
#if !NET40
[StringLength(256)]
#endif
The NET40 must be a predefined macro definition for .Net Framework 4.0
I had same problem, I solved this problem by following way.
Right click on page, select Property. in build action select Content.
Hope that this solution may help you.
I'm trying to compile my excel addin using C# 4.0, and started to get this problem when building my project in Visual Studio. It's important to tell you that I haven't had this problem before. What could cause this to happen?
When I had this problem I fixed it by turning off the 'Enable ClickOnce security settings'.
Menu: Project | 'Project name' Properties... | Security tab | 'Enable ClickOnce security settings' check box.
My guess is that you're not working with strongly named assemblies. I've had this error when two projects reference slightly different versions of the same assembly and a more dependent project references these projects. The resolution in my case was to remove the key and version information from the assembly name in the .csproj files (it didn't matter anyway), and then do a clean build.
Changes between the different assembly versions were compatible with the parts of the solution referring to them. If this is not the case with you, you might have to do some more work to resolve the issue.
NuGet
With NuGet it's easy to get into this situation if:
You install a package to one project in your solution.
A new version of that package is deployed to the package source.
You install it to another project in the same solution.
This results in two projects in your solution referencing different versions of that package's assemblies. If one of them references the other and is a ClickOnce app, you'll see this problem.
To fix this, issue the update-package [package name] command at the Nuget Package Manager Console to bring everything up to a level playing field, at which point the problem goes away.
You should manage NuGet packages at the solution level rather than at the project level unless there is a compelling reason not to. Solution level package management avoids the potential of multiple versions of dependencies. When using the management UI, if the Consolidated tab shows 1 or more packages have multiple versions, consider consolidating them to one.
See this answer.
Go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
I've had this problem. It happened because i had many projects pointing to the same assembly but from different versions. I solve it selecting the same version to all projects in my solution.
If you have changed your assembly version or copied a different version of the managed library stated in the error you may also have previously compiled files referencing the wrong version. A 'Rebuild All' (or deleting you 'bin and 'obj' folders as mentioned in an earlier comment) should fix this case.
If you tried all the other answers in this question and you:
Have multiple projects in your solution
Have a project (Project A) that references another project (Project B), whose project references a NuGet package.
In Project A, you used Intellisense/ReSharper to bring in the reference to the NuGet package referenced in Project B (this can happen when a method in Project B returns a type provided by the NuGet package and that method is used in Project A)
updated the NuGet package via NuGet Package Manager (or CLI).
...you may have separate versions of the NuGet packages DLL in your projects' References, as the reference created by Intellisense/ReSharper will be a "normal" reference, and not a NuGet reference as expected, so the NuGet update process won't find or update it!
To fix this, remove the reference in Project A, then use NuGet to install it, and make sure the NuGet packages in all projects are the same version. (as explain in this answer)
Life Pro Tip:
This issue can come up whenever ReSharper/Intellisense suggests to add a reference to your project. It can be much more deeply convoluted than the example above, with multiple interweaving projects and dependencies making it hard to track down. If the reference being suggested by ReSharper/Intellisense is actually from a NuGet package, use NuGet to install it.
you need to sign the assembly with a key. Go in the project properties under the tab signing:
Adding my solution for this issue for anyone it might help.
I had a ClickOnce solution throwing this error. The app referenced a common "Libs" folder and contained a project reference to a Foo.dll. While none of the projects in the solution referenced the static copy of the Foo.dll in the "Libs" folder, some of the references in that folder did (ie: my solution had refs to Libs\Bar.dll which referenced Foo.dll.) Since the CO app pulled all the dependencies from Libs as well as their dependencies, both copies were going into the project. This was generating the error above.
I fixed the problem by moving my Libs\Foo.dll static version into a subfolder, Libs\Fix\Foo.dll. This change made the ClickOnce app use only the project version of the DLL and the error disappeared.
Deleting the DLL (where the error is occurred) and re-building the solution fixed my problem. Thanks
When this happened to me with the WindowsAPICodePack after I updated it, I just rebuilt the solution.
Build-->Rebuild Solution
I encountered this problem after migrating an Excel Addin from packages.config to PackageReference. Seems to be related to this issue.
The following works as a crude workaround if you're not using ClickOnce (it will omit all the dependency information from the .manifest file):
Unload project, edit .csproj
Find the section looking like this:
<!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
Edit a renamed copy of the referenced .targets file (in my case, the file resolved to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets and I made a copy Microsoft.VisualStudio.Tools.Office_FIX.targets in the same folder - didn't check if it works from a different folder).
Find the GenerateApplicationManifest element and change its attribute Dependencies="#(DependenciesForGam)" to Dependencies="".
Change the section found in 2. to reference your edited .targets file instead.
This will have to be repeated whenever the version of the .targets file shipped with VS is updated (or you won't get the updates), but I'm hoping it will be fixed soon...
There were too many projects in my solution to go through and individually update so I fixed this by:
Right-clicking my solution and selecting 'Manage NuGet Packages for Solution...'
Going to the Updates tab
Finding the affected package and selecting Update
Clicked OK and this brought all instances of the package up to date
Unloading and reloading the problem project solved it for me.
I went to publish, application files, found the dll throwing the error changed it to 'Include' from 'Include (Auto)'. I can now publish.
Is your assembly properly signed?
To check this, press Alt+Enter on your project (or right click, then Properties). Go to "Signing". Verify that the check box "Sign the assembly" is checked and the strong name key file is selected and "Delay sign only" is unchecked.
Now Here is a different approach to the problem:
Right click on the project and select the 'Unload Project' option. You will notice you project becomes unavailable.
Right click on the unavailable project and select the 'Edit' option.
Scroll down to the ' < ItemGroup > ' tag that contains all the resource tags.
Now go to the reference that has been displayed on the error list, you will notice it it uses a single tag (i.e. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).
Change that to look as follows:
.
<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
< Private > True < / Private >
< HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
Save your changes, Right click on the unavailable project again and click on the 'Reload Project' option, then build.
This is caused when you change the version of the .dll that is referenced. You need to delete all items, or the .dll in the target build folder.
I got the similar compiler error. Once I add the dependent project of the dll file to the solution, issue resolved.
If your main project using some library projects and have reference to them, you can cause this problem if your project reference to a assembly dll file instead to library project when you change something in your library project (ex: rename a class).
You can check all references to your main project by view in Object Browser window (menu View->Object Browser). A reference to a dll file always has a version number. Ex: TestLib [1.0.0.0]
Solution: delete the current reference of your main project to the library project and add reference to that library project again.
After trying most of the solutions here, I finally just added a reference to the project from the click once project, this changed it to Include (Auto) from Include and it finally worked.
What helped me was I went onto Package Manager Solution and looked at the installed package which was causing the issue. I saw that several projects were referencing the same package but different versions. I aligned them based on my needs and it worked.
I had this in a solution w/ 6 projects.
One of my projects was referring to the named assembly as a file reference. The others were all pointing to the project reference.
I usually get a different error in these cases.
My solution was to delete the named assembly anywhere it was referenced and add it back.
Once I worked through the project, ths problem disappeared.
Before doing this, I tried cleaning the solution as well as making sure none of the projects were signed.
hope it helps someone...
If its a mismatch of a dependencies dependencies, go to the NuGet package manager at the solution level and check the Update and Consolidate tabs, harmonise it all.
I recently hit this problem. In my case, I have NuGet packages on different assemblies. What I had was different versions of the same NuGet packages associated with my own assemblies.
My solution was to use the NuGet package manager upon the Solution, as opposed to the individual projects. This enables a "consolidation" option, where you can upgrade your NuGet packages across as many projects as you want - so they all reference the same version of the assembly.
When I did the consolidations, the build failure disappeared.
I also bump into kind of problem, all I just had to do is delete the .dll (can be found in reference) that causing the error and add it again.
Works like a charm.
Try with update-package -reinstall -ignoredependencies
Just go to Publish -> Application File -> And change the effected dll publish status from prerequisite to include!
This worked for me!
In my case, I upgraded the project to .net 4.7.2 but still built in old visual studio version (2015).
When i built the project in VS 2019, the build failure disappeared.