Develop Reference

Reference seemingly not working, no apparent error thrown

I have superficial knowledge on referencing libraries in projects. Usually most of the time a simple 'add reference' and then browsing to the appropriate path, just works. I am following an issue I will try to explain , and show all the approaches I tried to tackle it.
I am trying to use AutoIt. In their website it is stated that simply adding the .dll and using it, is enough to integrate their functionality in visual studio.
I am doing just that but for the moment I can not get my head around what is happening.
AutoItX is a public static class, as also the Run function is the same (public static). After adding the reference I can navigate to the appropriate .cs (if I control click on it for example). So the class AutoItX is not something unknown for the project. Moreover, the function Run indeed exists
however not inside the project itself. AutoItX also needs staff from (dont know if it is important):
The main error is that AutoItX doesnt exist in this context.
I have tried to register the dll, I have tried to add the com reference and remove it, I have tried to move the .cs files inside the project. None of those corrected the issue.
Any help would be valuable. If I missed something and you need extra info, I am willing to provide it. (Latest vs, latest autoit version, .net framework type of project).

Actually the above works.
For future reference.
The reason I did not try it first was, that they propose in their website to reference the autoItX.assembly.dll. This is probably deprecated and does NOT work anymore.
Second, if you have already referenced it , downloading this from NuGet WONT fix it.
Finally, the NuGet package does NOT work with .net CORE but ONLY with .net Framework project

I installed AutoItX.Dotnet 3.3.14.5, my test is no problem.
You can refer to my steps to create a new project to test it.
Right click References=>Manage NuGet Packages=>Browse=>AutoItX.Dotnet=>Install
Running result:

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

How to deploy a DLL that is constantly changing?

I have created several small applications that use my own DLL. The problem is, this DLL is constantly changing. My current solution to this problem is that I have a Setup project in the class library solution that creates and registers the DLL. In all my applications I then have to open the solution and re-reference the newly created/registered DLL. Then I have to re-compile their setup projects, uninstall the old applications, and then re-install the new application.
There has to be a better way and I'm just not sure because I'm fairly new to all this. I have looked into ClickOnce but I don't think that will solve my issue as I cannot publish a class library. I have looked into checking version numbers but I must be doing something wrong because it doesn't work either.
I understand that once a DLL is created and being used in an application it should essentially not be touched. I do not have that option in this situation. It is constantly updated. Done.
So, is there a better way? A point in the direction of a guide or related question/answer/forum would be greatly appreciated.
Edit: The DLL is not constantly changing during runtime but it is constantly evolving to allow more functionality and detail within the other applications. Also, one big thing I guess I should have mentioned is the Public interface is constantly chaning - usually adding new methods.

Make sure the references to your DLL specify SpecificVersion=false. Then just deploy each new version into the GAC and that should do the trick.
Eventually, you can also manually force versions using Binding Redirection.

A solution you can try is to use a single solution for your project and reference the project wherever it needs to go.

Check out NuGet
You could set up an internal Nuget repository (really just a folder that stores nupkg files.) Then when you build a new DLL, you can update the apps as needed in studio. This would ensure it had the latest version. They shouldn't need a redployment unless there are bugs in the DLL that you're fixing.

One solution is as follows:
Physically separate the interface from the implementation. e.g. AssemblyA is the interface, the application (AssemblyB say) knows only the interface at compile time. The implementation (AssemblyC) also knows/references AssemblyA of course. The point being that AssemblyB does not reference AssemblyC. This will require you to use an IoC container (like MS Unity 2.0 but there are many others) in order to resolve and instantiate your concretes at runtime.
Write an update process that finds the new AssemblyC.dll, replaces the local copy and uses reflection along with the IoCContainer to 'load' the new implementation at what ever interval you require, typically app start up.
The above relies on your interface being stable. If it isn't, you may be able to write a (more) stable Facade.

Working with Common/Utility Libraries

At the company I work for we have a "Utility" project that is referenced by pretty much ever application we build. It's got lots of things like NullHelpers, ConfigSettingHelpers, Common ExtensionMethods etc.
The way we work is that when we want to make a new project, we get the latest version of the project from source control add it to the solution and then reference the project from any new projects that get added to the solution.
This has worked ok, however there have been a couple of instances where people have made "breaking changes" to the common project, which works for them, but doesn't work for others.
I've been thinking that rather than adding the common library as a project reference perhaps we should start developing the common library as a standalone dll and publish different versions and target a particular version for a particular project so that changes can be made without any risk to other projects using the common library.
Having said all that I'm interested to see how others reference or use their common libraries.

That's exactly what we're doing. We have a Utility project which has some non project specific useful functions. We increase the version manually (minor), build the project in Release version, sign it and put it to a shared location.
People then use the specific version of the library.
If some useful methods are implemented in some specific projects which could find their way into main Utility project, we put the to a special helper class in the project, and mark them as a possible Utility candidate (simple //TODO). At the end of the project, we review the candidates and if they stick, we move them to the main library.
Breaking changes are a no-no and we mark methods and classes as [Obsolete] if needed.
But, it doesn't really matter because we increase the version on every publish.
Hope this helps.

We use branching in source control; everyone uses the head branch until they make a release. When they branch the release, they'll branch the common utilities project as well.
Additionally, our utilities project has its own unit tests. That way, other teams can know if they would break the build for other teams.
Of course, we still have problems like you mention occasionally. But when one team checks in a change that breaks another team's build, it usually means the contract for that method/object has been broken somewhere. We look at these as opportunities to improve the design of the common utilities project... or at least to write more unit tests :/

I've had the EXACT same issue!
I used to use project references, but it all seems to go bad, when as you say, you have many projects referencing it.
I now compile to a DLL, and set the CopyLocal property for the DLL reference to false after the first build (otherwise I find it can override sub projects and just become a mess).
I guess in theory it should probably be GAC'ed, but if its a problem that is changing a lot (as mine is) this can become problematic..

Lingering assembly dependency in C# .NET

My C# project - we'll call it the SuperUI - used to make use of a class from an external assembly. Now it doesn't, but the compiler won't let me build the project without the assembly reference in place. Let me elaborate.
This project used to throw and catch a custom exception class - the SuperException - which was derived from the standard System.Exception and lived in a separate, precompiled assembly, SuperAssembly.DLL, which I referenced.
Eventually, I decided this was a pointless exercise and replaced all SuperExceptions with a System.SuitableStandardException in each case. I removed the reference to SuperException.DLL, but am now met with the following on trying to compile the project:
The type 'SuperException' is defined in an assembly that is not referenced. You must add a reference to assembly 'SuperException, Version=1.1.0.0 (...)'
The source file referenced by the error doesn't seem relevant; it's the project namespace that gets highlighted in the IDE.
Now, here's the thing:
All uses of SuperException have been eliminated from the project's code.
Compared to another project that compiles fine without a reference to SuperException.DLL, I only reference one more assembly - and that references nothing that my project doesn't reference itself. While it's possible that any of these dependencies could throw SuperExceptions, I'm only catching the base Exception class and in any case... the other project builds fine!
I've done Visual Studio's "Clean Solution" and cleared everything out by hand, many times.
It's not the end of the world to include this reference, I just don't see why it's necessary any more. Nrrrgg. Any pointers welcome!

It's likely a transitive reference, where some type method call returns an instance of SuperException boxed ("downcast") as e.g. Exception, but from inspecting the code in the transitively included code, i.e. code from your external method calls, the compiler knows that you need to be able to have information about that type at some point.
Resharper would tell you where it's the case that you need to add a reference, and you could use Lütz Roeder's aka RedGate's Reflector to scan compiled IL for a reference to this type in two ways: 1) use the search-facility, 2) open each public type you're using and for that one which requires the "ghost" assembly, it will ask you to specify its location.
This most often happends to me when I reference Castle.Windsor but not Castle.MicroKernel. :p

Exit Visual Studio
Delete the bin and obj Folders in your solution directory
Restart and see what happens

I agree with the other comments here.. There is a reference, in plain text somewhere !
I have had similar problems in the past where searching through the project files returned nothing, turns out it was in some other file that wasn't automatically picked up in the search.
I don't think that creating a new project is the solution here.. You need to be positive that NONE of the references in your dependency tree use SuperException.. NONE
I have never experienced this to the point where I have needed to literally wipe the project, I have always found the reference somewhere. Ensure you are searching every file.
EDIT:
Just a point to add, if the location pointed to by the error seems random, that can often mean there is a mismatch between the compiled source and the source code file.. Is this a ASP.NET application? I have had it before where the compiled DLL's haven't been replaced on a rebuild in the ASP.NET temp folder causing things to get.. Interesting when debugging :)

I don't think this is a code issue. What I can see happening is that one of your existing references probably rely on that type in their own types which you are probably creating in your application.
If that is the case you do need that reference even if you don't explicitly use the type and even though the other referenced assembly has its own reference. You sometimes get that issue with 3rd party components which need references to types that you haven't referenced. The compiler is obviously seeing something in one of your existing referenced assemblies and is expecting you to referenced the dependent one.

Since it's a compiler error, there must be a reference or use of SuperException somewhere in the project.
Do a find/replace in the entire project or solution for that type and remove every reference (it's possible you already did this).
If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Take the line that the compiler is showing the error on and start tracing the inheritance tree of the objects used on that line, you might find the source of it that way.

Thanks for your answers so far. I've tried every suggestion (except one) to no avail.
The suggestion I haven't tried is to create a new project and add all my stuff to it, the thought of which really tests my will to live. ;) I may try this tomorrow if I can be bothered. Thanks again.

There is really nothing very mysterious about VS projects nowadays - it's all text files, etc. SOMETHING must reference that class/dll, and that something must be part of your project.
Have you really grep'd or findstr'd the whole solution tree, every single file, for a reference to that exception?

This sounds pretty strange. Here's what I would check next:
Check that there's nothing lingering in your Properties/AssemblyInfo.cs file.
Check that there's nothing lingering in your SuperUI.csproj file.
Delete all references and re-add them.

Try creating a new project, and adding all your classes to it.

grep your project folder. It could be a hidden reference in your project, or a project that your project references. Cleanse with Notepad if needed.

If you reference any types that inherits from SuperException (even if the type defined in another assembly), you need a reference to the assembly that SuperException is defined in.
Seconded on that.
You might not be referencing SuperException, but you might be referencing SpecializedSuperException, which is derived from, or somehow otherwise uses SuperException - your grep of the project for SuperException won't be catching it though.
Try have a hack with the trial of NDepend

This is where tools like Resharper really pay off -- a simple Find Usages usually tells me of such "ghost dependencies" several times.
Maybe you could go to your definition of the SuperException class and try to Find All References(). You might also want to investigate if the assembly SuperException is has a circular dependency on your main assembly (e.g., main assembly depends on exception assembly depends on main assembly...).

I’ve had a very similar assembly reference issue that was happening when my C# library had a dependent C++/CLI assembly.
The problem that was I was inheriting a public class from that C++/CLI assembly in my C# assembly library. That meant that the inheritance chain was spanning across multiple assemblies.
I was hoping that any client would be smart enough to indirectly load the C++/CLI assembly any time the C# library needed it, but that was not the case even at compile time.
I got rid of this problem by breaking the inheritance between the classes that were spanning across those two assembly libraries and using aggregation instead.
My client was finally happy and did not require the C++/CLI assembly as a dependency anymore.
In your word you would probably have to make sure that SuitableStandardException does not inherit from SuperException in order to eliminate the SuperException.DLL as a reference.
Use encapsulation instead of inheritance and create a SuperException data member in your new SuitableStandardException.
If that does not solve it, you might have more classes spanning inheritance across some assemblies, in your case SuperAssembly.DLL and superException.dll.
If you can't find all of them try this trick:
Make all your public members and classes in SuperAssembly.DLL internal.
In the SuperAssembly.DLL make friends with SuperException.DLL:
[assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
Make sure that they build and remove the SuperAssembly.DLL reference from any client that already references SuperException.DLL.

grep -R SuperException * in the base of your project (get grep from somewhere first) just to be sure.