Develop Reference

Outdated Project Assembly loaded when running in Experimental Instance

I have two C# projects, A and B, in VisualStudio 2010. Project A is a class library. Project B is a ReSharper-Plugin project that references project A (ProjectReference). Both projects compile and worked property when I ran project A in the Experimental Instance.
Now, recently I renamed a static class, with some extension methods, in project A. Both projects still compile. But when I run project B I get an TypeLoadException for the new class name. When I change the class's name back, everything works fine again.
My guess is that project B is compiled against the new code, but run against an outdated dll. I tried everything from clear, over rebuild, to restart, but to no avail. I also manually checked that a fresh dll from project A is placed in project B's bin/Debug folder, which is the case. And I copied over the dll manually, after building project A. The problem persists.
Now I ask myself whether there is another location where the dlls are copied to before running the Experimental Instance. Is this the case? If so, where to? Are there any other places where the old version could come form? Or is there even something completely different that could cause the problem?
Thanks in advance!

Ok. Did you reference the DLL or the Project? In a Visual Studio Solution you can reference projects. If you reference project A in project B then B should always use the latest code from project A.

I managed to figure it out myself, thanks to the right keywords on Google (MissingMethodException and ProjectReference) that led me to a blogpost about a solution to the same symptom. In my case it was not the GAC that caused the problem, but the cached assemblies under
C:\Users\{name}\AppData\Local\Microsoft\VisualStudio\10.0Exp\
This is the location where all the assemblies of the Experimental Instance go. Here lay an outdated VsExtension that depended on project A and within it there was an outdated copy of project A that was loaded. The loading of the new version from the project reference was simply skipped, since a copy of the assembly (with the same version) was already loaded.
So the problem was ultimately caused by the removal of the extension from my solution. From this point of the extension was no longer updated by VS, but it was also not removed! Lessons learned: After major changes of your infrastructure you may want to delete all cached assemblies below the above path...
Thanks for the help, everyone!

Visual Studio saying name doesn't exist in current context

I am calling a static method on a class like
Foo.bar()
Visual studio's intellisense recognizes Foo and autocompletes bar for me (it highlights Foo and everything like it is working fine). Everything looks fine until I go to build the project, and it throws an error saying the name Foo doesn't exist in current context.
I am using this static method call in other files, so I know the class is ok. The situation is too big to post code, so I am mostly looking for reasons to start looking into that would cause intellisense to function normally but get errors on compile like this.

I've seen this error caused by differing versions of the .NET framework in the different projects. The Class Library I built was 4.5 and the application was 4.0, but the only error it gave was namespace errors. Changing the framework version on the class library and rebuilding it, then the application, resolved the error.

This can occur when namespaces, classes and variables become tangled when they have the same name. I have suffered with this before. Intellisense told me I was right, the compiler told me I was wrong! I trusted the compiler!
You have 2 options that I can think of
Search your code for Foo, and see it it is being used for something other than the static class.
Fully qualify the Foo.bar() call. MyApplication.This.That.Foo.bar();
Do it in that order...it's better to elegantly resolve the issue so you can just call Foo.bar() as this is more readable and maintainable than having MyApplication.This.That.Foo.bar(); all over the place!

In my case I was missing a } at the end of one of the methods in the middle of the code which was causing the program not see the rest of the code and complain about the Methods I have defined after that point.

Old thread I know, but I've encountered this issue when referencing a static method from within a unit test project - intellisense said the method was there, but when I tried to build/run the test (in Debug mode) I got the error 'name doesn't exist in current context'. In order to fix it I had to rebuild the project containing the referenced static method in Debug configuration (it had only previously been built in Release configuration) - after this the test built and ran OK.

I know this is a bit old topic, but I just experienced the same and for me it was because the file was not actually included in the solution.
I properly happened because I had renamed the class and then the file, which caused Visual Studio to still know the class and the namespace, but the compiler did not get the file as the renamed file was not included.

Consider doing a Clean and then a Build on the project with the problem. It is possible for the editor and Intellisense to correctly discover the class, while the compiler works with files that are out-of-date. (I had this same problem, and that's how I resolved it.)

this is an old article I know, but I just encountered this issue and has been puzzling me for couple of days, and eventually got to it: click on the class file, in Solution Explorer, then look at the Properties tab; make sure Build Action is set to "Compile".

Adjust the related file. If the error code in Default.aspx.cs, you need to change the top line in the file Default.aspx as below:
Replace "CodeFile=" with "CodeBehind"
Hope this can help.
-Thanks, Thai_FUV

I have run into this probelm a few times and so when I do, the first thing I check is if the assembly not recognized has any Nuget packages. In my cases they always have and I simply forgot to install the same packages in the assembly of which the reference to the un-recognized assembly is in. A re-build command and problem fixed. I hope this helps someone. This same error message can be given for multiple things so this particular case, may not apply. If you have not used Nuget than I would suggest trying the other answers

I also was running into this issue creating a data access layer and had static methods being called with the same symptoms: Intellisense finding it but not the compiler. I tried many of the above, including fixing the .Net version.
When adding the source files to the project I also changed the namespace.
With the file with the issue, I forgot to change the namespace to match when it was imported at another time.

Closing all tabs of MonoDevelop. Then Closing MonoDevelop. Finally opening MonoDevelop again solved the problem for me.

Mine was a little more convoluted solution. Project A referenced projects B and C: both references had Copy Local to true and both produced assemblies with identical names. When building the referencing project, the output assemblies from projects B and C were copied and one overwrote the other because they had the same name. VS was then looking for the references within the build directory and only found the assembly that had "won."

In my case I had to reload the project that was marked "missing".
Project > Unload Project
Project > Load Project
Clean, Build Solution

My solution to this problem that occurs every now and then:
Find the class that is giving you problems in the Solution Explorer and "Exclude From Project"
Rebuild that assembly (let's call it "A")
The project that used the file ("B") will ask you to "Reload" project, wait
Add the file back into assembly A, that you just removed it from, and rebuild
Now, reload project B
Then the file was found in VS and all was well.

Changing the id of the control resolved the issue for me. Apparently the id of the control existed in another part of the solution.

In my case, I was missing the following lines in my csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DefineConstants>TRACE</DefineConstants>
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
Once I added this, I could see the variables while debugging

Adding a ProjectReference to a project that is not in the same solution

While doing some refactoring of our projects and solution files, i have separated some .sln files to contain less projects.
Occasionally i need to reference some projects from outside the scope of the current .sln file.
For example, my initial state was this:
SOLUTION A
PROJ A
PROJ B
After refactoring it would look like this:
SOLUTION A_NEW
PROJ A
SOLUTION B_NEW
PROJ B
My question is -- Is it possible to add a ProjectReference node to a project that is not defined in the same VS solution? (in my case, having PROJ A have a project reference to PROJ B).
Also, if it is possible, is that recommended?
I know that this is not possible from the VS IDE, only by editing the .csproj file manually.

You can't do this. A project reference includes an identifying GUID for the referenced project, which is maintained in the solution file in order to track solution build options and dependencies. If you try to reference a project that is not in the solution, Visual Studio will complain.
You can add a file reference to the assembly produced by a project that's not in the solution, of course.
UPDATE: Since this got downvoted, I'll refine my answer.
Though it's technically possible to craft a project file that references another project outside the same solution, Visual Studio won't help you to do it easily. One very good reason why it's a bad idea to do this (that I've observed) is that whatever Solution Configuration and Platform you're building (the referencing project) will be ignored if MSBuild decides to build the referenced project - the default Configuration and Platform specified in that referenced project file will be used instead. Thus you may end up with a mixture of binary types in different folders.

Temporarily add the project to the solution, add a reference to it, unload the project that now has a reference added to it, remove the referenced project, reload the project with the reference.
If you don't unload the project then the reference will be automatically removed by Visual Studio when the referenced project is removed.
As you can probably tell, Visual Studios not designed to do this and you'd be better defining a build order for the solutions and use assembly references instead.

You can definitely add a project to a solution A that is in solution B. There is not any problem with that. From my experience, it's not something that I usually have done or do, but sometimes need to. This can be especially true on large projects where you need different nodes of your architecture to reuse same code base.
Hope this helps.

How to set "Specific Version" property for project references in Visual Studio

I have got a Visual Studio Solution containing several projects and have set up the references between the projects as project references.
When a reference to an assembly is added, the references' properties contain a setting for
Specific Version = True|False
This property is missing for project references. How can it be set? I'd like my solution to load any available assembly (no matter what version) in the bin folder.
I've had a problem when a workflow instance (Workflow Foundation) was deserialized and the dependencies were updated meanwhile.

I think the problem is that what you are asking is not possible directly with a project reference, I think that always implicitly turns into an 'explicit version', because of the nature of the link.
The way you could do this (calling the currently referenced project A, and the referencing project B):
Have the project you want to reference in your solution, just like you do now with the project reference
Explicitly set the dependency chain so the 'referenced' project is built first
Build the referenced project A once first manually
Create an assembly reference in project B to the results from the build in project A
Set the assembly reference to 'Specific Version = false'
The build order (dependency) will guarantee that A is always built before B, and B will reference it from the binary output directory of A.
(altho, it's a little brittle and I would not recommend it since it's easy to get wrong results if the settings are not all right, or the sun aligns with the stars wrong, or some such)

I might be misunderstanding your question, but when you add a project reference, the project's assembly is always loaded into any project that references it when the project is built. Therefore, you'll always have the latest available assembly in the bin folder for that project. VS treats projects differently than other assemblies in that regard.

You can add references to project output dlls instead of projects. Then you will be able to set Specific Version setting.

I have found the solution to my problem. It's described pretty detailed here.
The problem is not a matter of wrong project references, but more a de/serializing of workflow instances question.
Thanks to everybody who tried to help.

Assembly dependencies with .Net projects

If I have an assembly (A) which references another assembly (B).
I want to reference A in a project, I add the reference and it copies A into my BIN directory. It does not copy B as well, even though A depends on it, so the code doesn't compile.
How can I set things up so that whenever I reference A, both A and B get copied to my bin directory?

In Visual Studio, add each project to the same solution. Ensure you use Project References instead of direct file references (ie browsing for the assembly).

I dont think there is any way around what you ask other than to explicitly add both. I dont think however adding projects for the sake of getting references copied is a viable solution to the issue. Not all projects that a solution depends on should necassarily be added to the solution. This would completely depdend on your overall project structure, processes, source control, division of labour, etc

Reference both A and B.

Unfortunately you'll have to manually add both. This is what happens to me as well whenever I use pre-3.5 versions of NHibernate: it requires both log4net and Iesi.Collections assemblies. So I have no choice but to manually include a reference to both in all my solutions that implement NHibernate.
This is more of an issue, of course, if you only have the DLLs. If it's a project that you have a codebase to Visual Studio itself will warn you beforehand that the references are missing.

How about adding them to Global Assembly Cache?