I've added a Fakes assembly to my Visual Studio 2012 unit test project, corresponding to my application project (the System Under Test), as described in Peter Provost's article. However, the project will no longer build, on account of an unresolved type reference in the generated Fakes code:
The type or namespace name 'FieldDefinition' does not exist in the namespace 'bc::ProductStudio' (are you missing an assembly reference?)
[C:\Users\arvek\Projects\Project\Project.Tests\obj\Debug\Fakes\bc\f.csproj]
C:\Users\arvek\Projects\Project\Project.Tests\f.cs
What's going wrong here? From what I know, this is supposed to just work, so it would seem to me there's a bug in the Fakes facilities.
This bug is present in VS2013 as well. Link to MSDN bug.
Work Around: Delete file .messages from FakeAssemblies folder.
The error is most likely due to bug in Fakes triggered by the faked assembly. I've submitted the issue to Microsoft.
One option that may help you diagnose the issue is turning on diagnostics for you fakes. On your .fakes file.
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011" Diagnostic="true" Verbosity="Noisy">
Also, make sure that your "MSBuild project build output verbosity" is set to Diagnostic. You can find this in Tools -> Options -> Projects and Solutions -> Build and Run.
Rebuild you test project and now your output window should be full of info including any failures for Fakes
Deleting Fakes folder will resolve this issue.
You're not going to believe this, but I was able to get the fakes working again by simply adding a new line to the file, removing that new line, and then saving what is effectively an unmodified file. After the next build everything was fine.
Things that make you go... hmm...
Related
I have been scouring the internet for an answer on this and could really use the help.
I've already looked at other posts regarding this error and none of those answers helped me.
The full error is,
The type 'xxx' is defined in an assembly that is not referenced. You must add a reference to assembly 'xxx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
The solution builds fine locally, but the error occurs when I trigger a build on the build server.
Here's what I've done so far in an attempt to resolve this:
Ensured all project references are correct(Had an Architect review it
with me)
Changed the 'SpecificVersion' property to true
Removed the reference and added it back(In VS2012 and edited
the .csproj file itself)
Built solution locally on the build server, it passes
EDIT - I should also mention I have built this solution on two different build servers and still get the same error
I'm using VS2012 and TFS2012 to do this.
I would really appreciate any help, thanks.
*UPDATE:*I just did an MSBuild on the build server but changed the configuration to "Release" and was able to reproduce parts of the error. Some key differences though is that the version it's looking for is suddenly 1.3.1.15 instead of 0.0.0.0 and the PublicKeyToken is no longer null. Does anyone know what this could mean? The assembly's version is supposed to be 0.0.0.0.
So after putting in a few more hours with my Architect, we found the issue. Our developers had multiple copies of the same dll buried in various folders in our Source Control. One of the projects was referencing the incorrect .dll.
After fixing the references and removing the extra uneeded .dlls, the error is gone and our builds are finally working! :)
You mentioned that you tried building solution on the test server. Did you use visual studio 2012 to build the solution or did you actually run msbuild?
The accurate test would be to use msbuild similar to this:
MSBuild MySolution.sln /p:Configuration="Debug" /p:Platform="CPU Any"
You can actually get the exact command by looking at the build logs for TFS Build, it will list the build command it executed and simply run it yourself (you'll need to remove extra stuff TFS Build adds for logging)
After that you can run the same command on your local machine and see if it passes.
Another thing to try is to set "copy local" for all assemblies in the project.
Hope this helps!
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
I would first like to admit that I am an extremely novice developer, so I'm doing my best to give all of the relevant information to make this question answerable:
So I'm trying to do some unit tests for NxBRE before I start attempting further work with the engine. I've downloaded both NxBRE and NUnit (version 3.2 and 2.6 respectively) and I've tested NUnit to make sure that it is working properly using a simple example that I could post here, but seems irrelevant to do so. What's important was that I was easily able to reference the nunit.framework.dll in the example, and the tested attributes compiled and the GUI ran the tests perfectly. I'm using SharpDevelop by the way.
I then opened up the provided NxBRE solution, which has two projects (NxBRE and NxBRE-UnitTest), added the same reference in the Unit-Test project to the nunit.framework.dll, and attempted to build the solution. I got a compiler error (along with the host of associated errors) stating that:
CS0246: The type or namespace name 'nunit' could not be found (are you missing a using directive or an assembly reference?)
Well, I was pretty sure I wasn't missing either, so I double checked the reference, and it seemed good (in that I re-added it in the way that I had for my test example). I even manually copied the .dll to the directories that were being accessed. I don't think it was an issue with NUnit itself, because I went back to my crafted example and it still ran fine.
Do you have any suggestions for trouble-shooting ideas or techniques that I should try?
I examined the .csproj file of the NxBRE 3 test project, and there is no directory path associated with nunit.framework.
In other words, the test project expects NUnit to be installed in the Global Assembly Cache. Could it be that you have not installed NUnit via its .msi file but rather unpacked it from a .zip file?
My recommendation is that you remove the nunit.framework reference from the test project and then add the reference again by browsing for the actual DLL file in the file system.
I have a WPF/ASP.NET project which I haven't worked on for a while (ResourceBlender.NET - http://resourceblender.codeplex.com/). The project contains a DataLayer and a Core layer, these are both used by the WPF application and ASP.NET project in the solution.
If the WPF project is set as the startup project and I try to build the application, I get "The type or namespace name 'whatever' could not be found (are you missing a using directive or an assembly reference?)".
The error list shows these when I try to build, run or debug, but double clicking and going to the error shows no actual errors in the editor and everything is highlighted as normal.
The ASP.NET project builds fine. I'm absolutely clueless on this one, as there are no obvious errors to fix - could it be metadata somewhere?
Check that all assemblies does not target the 3.5/4.0 Client Profile (It is probably the WPF application that is the culprit). This will cause exactly the error message you're describing.
This type of thing is really hard to debug without being able to see your solution setup, but here are the things I would try:
Expand the references in your WPF project, make sure they are all resolving
Double-check that none of your references have "specific version" set to True and point to an old/nonexistent version
Do a "Clean" on your solution, close VS and delete your bin and obj directories, etc. to clear out potentially old copies of dlls that may be messing up your build
Good luck!
Try the following:
Right-Click on the solution on do a "Clean Solution"
Try to build each project separately
Check the references on your projects for missing assembly references
Compile issues like this can be overwhelming. It's usually best to troubleshoot one project at a time as suggested in these tips:
5 Debugging Tips for a Solution That Won't Compile
Actually read the Output window text.
often errors or warnings that are pertinent appear in there but aren't obvious when following the Error List window links.
For about 2 weeks now, I have been unable to run any UnitTests (built in VS unit tests) for a project. Previously everything worked fine. The error message is:
Could not load file or assembly 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProjectName.XmlSerializers.dll" or one of its dependencies.
The project references System.Xml.Serialization and uses the XmlSerializer class; just like many other classes/projects I've written. For some reason, only this project is affected. It builds fine, runs fine, I just can't run my unit tests.
I've checked the directory, and all the dlls in that directory are Microsoft dlls. The dll that it is looking for obviously is not a Microsoft dll.
Anyone have any ideas?
Edit:
It apparently has something to do with using the XmlSerializer and it generating that file automatically instead of using sgen.exe. Here is a link to the MSDN article. From what I've been able to find, it has something to do with using the serializer with generics. None of the sources I've found seem to offer any way to make it actually work.
First enable loader logging (using FUSLOGVW.exe from the SDK) to confirm what is not being found.
Then use Reflector on all your assemblies to find the one that is trying to load the non-existent assembly. If you find no such assembly it must be being loaded dynamically, in which case attaching to AppDomain.AssemblyResolve should allow you to identify where.
try to copy all your source files somewhere, then delete the project and try to make it from scratch. Maybe something happened with project dependencies
Is your computer 64bit? I got the same error when trying to run a 64bit dll with NUnit that was set to work as an x86 assembly (using corflags).
You can probably find out from the error message (use FUSLOGVW.exe lick Richard suggested).
If that is the case you can either sent the dll or NUnit to run as the correct assembly using corflags.
Solution
As it turns out, the problem was with VMWare. I installed the latest version of VMWare, and it installed it's tools to debug in a VM. Something it installed or changed caused this problem. When I uninstalled VMWare, the problem went away. So, I reinstalled VMWare without installing it's debugging capabilities and the problem did not come back.
Workaround:
I still have no idea why this problem suddenly started occurring, but I found a hack to make it work.
I had to go to project properties => Build Events and add this line to the Post-build event command line:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" "$(TargetPath)" /force
This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"
Now it I can run my tests and step through them. The problems I have now are 1) I have to remember to copy the dll to that directory every time I change something in the classes that I am serializing, and 2) I now get a ThreadInterruptedException when a test finishes running; thus 3) I can only run one test at a time.
Not a good solution, but at least I can limp through. Unfortunately, redoing everything, as Nikita Borodulin suggested, is not an option.