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.
Related
I've written a feature that I want to unit test. I've been following Jason Weimann's video. (I haven't found a tutorial for VS Code, so I went with one on Visual Studio.) Basically, it says:
In Unity, go to Window -> General -> Test Runner.
Create an EditMode test assembly folder (creates an asmdef file by itself).
Create an assembly definition file in the Scripts folder, and reference it from the EditMode asmdef.
As soon as I add the scripts asmdef file, I get a couple of CS0234/CS0246 errors, for example
The type or namespace name 'InputSystem' does not exist in the namespace 'UnityEngine'
The type or namespace name 'IInputActionCollection' could not be found
Which are all in the class generated by the new input system. Oddly enough, VS Code doesn't mention a word about these errors.
There are also 2 warnings, both saying "Assembly for Assembly Definition File X will not compile, because it has no scripts associated with it." First one is about the test asmdef, second one about the scripts asmdef.
I thought I'd fix the warnings first. I found this link which says the issue is fixed with Unity 2020.1.3f1, so I upgraded the project version to 2020.1.6f1. Poof, warnings are gone - but not the errors.
I also tried what this post said - which is related to the first error above. No success with it.
If that helps, I already have installed the unity package Input System 1.0.0
Where should I go from here?
I looked for the answers here and there with no luck, so I decided to ask out.
I want to implement openalpr (open source Automatic License Plate Recognition)
repository on my own PC and I am following this video to accomplish the task. I have done all the steps he did and at the end, when I tried to build it but, in one of the .cs code there is CS0246 error that says:
Error CS0246 The type or namespace name 'AlprNet' could not be found (are you missing a using directive or an assembly reference?) number_plate c:\users\sohib\documents\visual studio 2015\Projects\number_plate\number_plate\Form1.cs
I could only find AlprNet in my D:\Projects\plate_recognition\openalpr-master\src\bindings\csharp\AlprNetTest and it is in .csproj format.
AlprNet is not in .dll format like other references so I cannot reference it in References.
I found some say that it might be because of different versions of .NET Framework platforms. I almost did nothing to check that, because I don't think it's related to .NET
In my mere opinion I should link that AlprNet.csproj to get its content, but I'm not sure. If someone can help get around this issue, I'd be very grateful.
If it's not a .net Assembly (dll) that's referenced and it's not a nuget package, then check that the code isn't expecting the Assembly to already be present in the Global Assembly Cache (If you have access to another developer machine where this works, this is easy to check).
Failing that, adding the .csproj to your .sln and then referencing it sounds like the way to go (provided you have access to that of course!).
I'm using Visual Studio 2013, and I'm getting an error in my C# code that I can't figure out. I'm working with the Microsoft Kinect SDK, but I'll keep it general.
I downloaded the SDK, and I can get the included sample programs to build and run. But when I try to use the code in my own project, I get the
Type or namespace name 'Kinect' does not exist in the namespace 'Microsoft' (Are you missing an assembly reference)
error.
The thing is, I'm not missing an assembly or reference. I have it added to the project's references, and the path is valid. Also, the using statements at the top of the file will autocomplete to "Kinect" for me. If I start typing using Microsoft., Kinect will appear as an autocomplete option.
What are the steps to debugging an error such as this? Could it be a 32/64 bit issue? I tried using Dependency Walker to look at the Kinect DLL, and while it throws some errors (Error: Modules with different CPU types were found.), it doesn't show any issues that I don't see with other DLLs that I'm using successfully.
What are some other potential issues that might cause a problem with DLLs not being recognized?
1 - Try going to your project settings and verify the version of the .NET framework it uses.
The best to do is to choose the same version as the external libraries.
If it's a client profile, it will very often bring that exact problem. (I'm not sure what the client profile is, but I ended up never using it...)
2 - Check if any of your references got an exclamation mark.
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...
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.