hi
I have delivered a vb.net solution which contains 3 projects (Biz, Data Access, Presentation).
Recently, when I compile it, I get the following error:
"The located assembly's manifest definition does not match the assembly reference(Exception from HResult.....)"
When I double click on it, unfortunately it says to me that "The document cannot be opened. It has been renamed, deleted or moved"
How can I solve it? I should say that did several things such as "Clean solution, rebuild it" but it didn't work.
What's your suggestion?
thank you
You should look at this post on StackOverflow: The located assembly's manifest definition does not match the assembly reference
I believe it answers the same question you present here.
It means one of the assemblies referenced in your project cannot be located. It has located the assembly but it doesn't fully match it, for ex either the version, culture or public key token is different.
Related
There are already multiple similar questions on SO, but, they are asking how to resolve. My question is slightly different. I have read the other posts and I can see how to resolve it - (by adding the namespace to the routes)
The error I am getting is
The request for 'Home' has found the following matching controllers:
_01.Ui.Controllers.HomeController
ZurbMvc4.Controllers.HomeController
Now, the project USED to be called ZurbMvc4. I've now renamed the solution and projects, and performed a find and replace to rename ZurbMvc4 to _01.Ui
My question is, how has MVC still got a reference to ZurbMvc4 ? Performing searches (find) brings no results. I'm searching for entire project.
Opening up the solution file and the project file in notepad still finds no reference.
How do I find the reference to this old controller.
Deleted the obj and the bin folders from within Windows Explorer, a quick rebuild and its solve the problem.
Getting error
A reference to "file path\file.sln"could not be added. please make
sure that the file is accessible and that its is a valid assembly or
COM component
You mean adding a reference inside a project?
If is this, you can´t add a reference to a whole .sln, you will need to choose, for example, a valid .dll of the service you are trying to reference.
A reference to "file path\file.sln" could not be added.
That's a solution file.
[...] and that its is a valid assembly or COM component
A solution file is not an assembly or a COM component, hence the error. You need to add a reference to an actual assembly. If it's a project in your current solution, add a Project Reference. If it's not in your solution (and for whatever reason can't be added, though I highly recommend adding it if at all possible) then you'll need to add a reference to the compiled .dll of the referenced project.
You can't add references to solution files, project files, anything like that. Those are just XML metadata about projects. You need the compiled output, the assembly.
While updating the dataset in rdlc report file ,I got below error.
Could not load file or assembly 'PayPalCoreSDK, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
How can I resolve this as i am unable to work on rdlc anymore .Kindly help here.
This question is kinda old already, but just in case someone searching for an answer for this problem gets here, I'll say this has happened to me several times. Apparently there's some problem when working with a solution containing multiple projects. You gotta remove all references to other projects on the project you are trying to change the rldc report, once you do that u'll be able to refresh your report source in design. Hope this helps someone.
Question:
If I have multiple projects in one solution is it still considered a single assembly?
Background Information:
I'm aware the 'MyApplication/Properties/AssemblyInfo.cs' file exists. Further, I confirmed that when I:
Add a project to the solution.
Appropriately reference the newly added project.
Lastly, Build the solution.
The 'MyApplication/Properties/AssemblyInfo.cs' file has not changed. This leaves me to believe, and please correct me if I'm wrong that I'll have met the demand.
Thank you
No.
Each project is compiled into one assembly in your case. The assemblyinfo.cs file (for each project) should not change at all when you compile anything. Also, that file's name is not important at all; it's the global attributes inside it that cause various properties of the assembly being created to be set. That file's name and location are simply a convention.
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.