Reputation: 25280
I am currently working on a server control for other applications in our company to interface with a WCF service. Every time I make a change code change and recompile the control, I increment the the AssemblyVerison and AssemblyFileVersion class in the AsseemblyInfo.cs by one. For example, my latest build went from 1.0.07.0 to 1.0.08.0.
When the consuming application updates the file by copying the latest file in the bin directory and tries to compile, they receive the following error:
The type or namespace name 'MyControl' does not exist in the namespace 'MyNamespace' (are you missing an assembly reference?)
In order to resolve this error, they have to delete the current reference and re-add the reference.
Is there any way to update the server control without having to delete and re-add the reference?
I am not strong naming the server control.
@JPunyon - Do you mean have the consuming application add the server control project to their solution?
Upvotes: 37
Views: 222781
Reputation: 453
While creating new Blank UWP project in Visual Studio 2017 Community, this error came up:
After restoring the NuGet cache the reference resurfaced in the Project.
Upvotes: 0
Reputation: 5402
If the code is working previously and is throwing errors now, as mentioned in the above answers one of the config could have been modified. In brute force approach, close the VS editor and delete .vs folder in the same directory of the .sln file. All the config will be cleared and picked up from the repo files.
Upvotes: 2
Reputation: 11
Delete 'Web.Debug.config' and 'Web.Release.config' file for your solution directory,it should remove all errors
Upvotes: 0
Reputation: 1120
If none of the solutions above worked, try this 10-second fix.
Navigate to the startup project in solution explorer. Right click, properties > Application > Target framework. Change the target framework to anything else. Press Yes for the confirmation dialog. Give the changes a few seconds to take effect, then switch the framework back to what it was before.
The error will hopefully go away for you like it did for me!
Upvotes: 15
Reputation: 1355
I found this issue in Visual Studio 2019 Version 16.4.4
I resolved most issues by discovering that the
packages.config
was missing the appropriate reference
eg:
<package id="System.Runtime" version="4.3.0" targetFramework="net461" />
Upvotes: 0
Reputation: 769
I encountered this error with an Azure DevOps Services (MS-hosted) build pipeline on a TFVC repo.
In my case, I was working within a branch and had accidentally added the reference from the package folder in trunk instead of from the branch. Once I added the reference from within the branch, it started compiling successfully.
I.e., while working on \branch-beta\sierra.csproj, I accidentally referenced \trunk\packages\delta.dll. Obviously, I needed to reference \branch-beta\packages\delta.dll instead. The mixup occurred because the path is not prominently displayed in the Add Reference window and I didn’t check carefully enough.
Upvotes: 0
Reputation: 758
In my case, I had to change the Copy Local setting to true (right-click assembly in solution explorer, select properties, locate and change value of Copy Local property). Once this setting was changed, publication of my WCF service copied the file to the server and the error went away.
Upvotes: 0
Reputation: 931
In my case it was a project defined using Target Framework: ".NET Framework 4.0 Client Profile " that tried to reference dll projects defined using Target Framework: ".NET Framework 4.0".
Once I changed the project settings to use Target Framework: ".NET Framework 4.0" everything was built nicely.
Right Click the project->Properties->Application->Target Framework
Upvotes: 42
Reputation: 320
I bumped the answer that pointed me in the right direction, but...
For those who are using Visual C++:
If you need to turn off auto-increment of the version, you can change this value in the "AssemblyInfo.cpp" file (all CLR projects have one). Give it a real version number without the asterisk and it will work the way you want it to.
Just don't forget to implement your own version-control on your assembly!
Upvotes: 1
Reputation: 66763
Right-click the assembly reference in the solution explorer, properties, disable the "Specific Version" option.
Upvotes: 19
Reputation: 176239
Are you strong-naming your assemblies? In that case it is not a good idea to auto-increment your build number because with every new build number you will also have to update all your references.
Upvotes: 2