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?
This question is related to
visual-studio
compiler-errors
reference
assemblies
The answer is
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
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!
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.
Delete 'Web.Debug.config' and 'Web.Release.config' file for your solution directory,it should remove all errors
While creating new Blank UWP project in Visual Studio 2017 Community, this error came up.
After the suggested remedy (restoring NuGet cache) the reference resurfaced in the Project.
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" />
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!
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.
Delete 'Web.Debug.config' and 'Web.Release.config' file for your solution directory,it should remove all errors
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.
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!
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.
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.
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!
While creating new Blank UWP project in Visual Studio 2017 Community, this error came up.
After the suggested remedy (restoring NuGet cache) the reference resurfaced in the Project.
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.
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.
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" />
Source: Stackoverflow.com