Moles does not show new Method Signatures after Changes in Class - visual-studio-2010

I had
class Voo
{
private static AnotherClass Doo(int id)
{
//do some stuff with id then return object of AnotherClass
return x[0];
}
}
and used this private with moles
MVoo.DooInt32 = delegate ...
NOW I changed the method to:
class Voo
{
private static AnotherClass Doo(string a, object b)
{
//do some stuff with a and b then return object of AnotherClass
return x[0];
}
}
BUT moles does not give me the new signature. Sill MVoo.DooInt32
but I expect MVoo.DooStringObject
I removed the moles reference, cleaned, rebuilded. No positive result so far.
Any Ideas?

You need to be sure to delete the mole assembly file (.dll), rebuild the test project without the mole type, and then add it back in. This process is thorough, and has always worked for me, in this situation:
Remove the mole assembly reference from the test project
Delete the .moles file, named after the assembly in question
In Solution Explorer, show all files in the test project
Expand the hidden "MolesAssemblies" folder
Delete the desired _.Moles.dll file and corresponding XML files
Remove (not delete) test files that reference the mole assembly
Rebuild the test project
Select the "Add Moles Assembly" context menu option, on the desired test project reference
Add test files that were temporarily removed from the project
Rebuild the test project

You have to delete your moles file for that assembly something like voo.moles and then create a new one.

Related

In Visual Studio 2017/2015 C++/CLI Find All References FAILS

I am having difficulty with Find All References feature in Visual Studio 2017 (and 2015 at least, may be older too).
I have this defined in one project (C#):
public static class AlgorithmNames
{
public static readonly string
FaceAnalyzerAlgorithm = "Face Analyzer Algorithm (C++)",
StaticFaceAnalyzerAlgorithm = "Static Face Analyzer Algorithm (C++)";
}
and it's used in another project (C++/CLI) in the same solution like so:
public ref class FaceAnalyzerAlgorithm : AlgorithmBase
{
public:
property String^ Name
{
String^ get() override { return AlgorithmNames::FaceAnalyzerAlgorithm; }
};
...
When I right click Find All References on the definition of FaceAnalyzerAlgorithm (C#) it does not find the use just the definition even though the filter says "Entire Solution".
When I right click Find All References on the use (C++/CLI) it finds nothing and nothing happens in UI to indicate any activity. Go To Definition and Go To Declaration both end up in Object Browser.
Issues like this do not seem to happen when it's just C#, but as soon as there is C++ it fails miserably. Any fixes or workarounds welcome.

For a Maven project to access its own resources

I have two projects:
A project
B project (lists A as one of B's dependencies)
A has a method that relies on A's resource
When B calls A's method, A ends up access B's resource folder and thus is unable to find A's own resource files.
Any way around this?
In order to ensure that a project will always access its own resources, you need to load them using the Class#getResource method.
Example:
public class MyCalledClass{
public static void loadResource() {
new File(MyCalledClass.class.getResource("file.txt").getPath()); // Will retrieve the file called "file.txt"
// in the project where this class is
new File("file.txt"); // Will retrieve the file called "file.txt" in the project calling this method
}
}

Swift 2.0 / Xcode 7B5 - Classes can only be found if put in a certain file

I noticed that at a given point the class User could not be found when I wanted to use it in other classes. Nothing suspicious about it. At a given point I started to experiment with what place I put the code.
If I put all these classes together in one of my older files, all compiles. If I put them all together in a newer file, the other parts of my code consuming these classes do not compile. If I rename a file (from User.swift to AUser.Swift for example) nothing changes, meaning what compiles keeps compiling and what doesn't compile still doesn't compile based on name. It really seems to be the age of the file or something like that.
It appears as if everything I add later related to this particular cluster of classes will not compile in a newer file. These files are included when building, I checked that. There is nothing strange about the code I think:
import UIKit
public class User: AddressBookContact {
var home: Home?
var friends = [Friend]()
}
public class Friend: AddressBookContact {
}
class Session: NSObject {
private static let instance = Session()
override private init() {
super.init()
}
class func sharedInstance() -> Session {
return instance
}
static var loggedInUser: User?
}
Look in the File Inspector Utility pane (the right-hand pane). The file in question likely is not a member of the target.

How can I quickly create a class in the right place when following TDD using Visual Studio/ReSharper?

Suppose I'm following TDD and using VS/ReSharper. I start out writing a test like this:
[TestFixture]
class FooFixture
{
[Test]
public void ShouldDoSomething()
{
var foo = new Foo();
}
}
At this point, Foo doesn't exist. ReSharper suggests the option of creating the class, but it puts it right next to my test class in my test project, not in my real project. So I have it create the class, then move it to a new file, then move the file to the right place, and finally fix the namespace. This seems like a lot of work.
Is there a more efficient way to quickly create the Foo class and put it in the right place? It seems like the 'right place' could be guessed from the namespace of my test project.
Move types into matching class refactoring is used for this purpose.
You're expected to generate a number of business logic types in the current test class and then move them to matching files/namespaces in one go.
Note that this refactoring is available in the text editor and on Solution Explorer nodes, meaning that you can batch-apply it to a heck lot of files.

DeploymentItem fails copying directories when there are multiple test projects per solution

I have a number of test classes and methods that copy a particular directory like so:
[TestClass, DeploymentItem("LanguageData", "LanguageData")]
public class OcrTests
{
[TestMethod]
public void Can_Capture_Field()
{
// some code that expects the LanguageData directory to be in the test results Out directory
}
// etc
}
[TestClass]
public class OcrBuilderTests
{
[TestMethod, DeploymentItem("LanguageData", "LanguageData")]
public void Can_Build_Specific_Ocr_Engine_Implementation()
{
// some more code that expects the LanguageData directory to be in the test results Out directory
}
// etc
}
Those tests are in a single assembly and all the files in the LangaugeData directory have their Copy to Output Directory set to Copy Always.
It all works fine and the directory is copied to the test results Out directory as long as I only have that one test assembly loaded into the solution or that's the only assembly I run tests from (i.e. run tests only in current context/class).
As soon as I add a second assembly and run all the tests in the solution then that directory no longer gets copied, but any other DeploymentItems that are just individual files seem to get copied fine.
The tests themselves all still run, but the ones that depend on that directory crash. Presumably that's because MSTest can't find the directory - perhaps it's expecting it to be in the build directory of one of the other test assemblies?
Any ideas what it is about multiple test projects that's preventing the copy, and what I can do to get around it, short of adding every single file in that directory as an individual DeploymentItem?
This question is quite old, but could still benefit others. Especially since I ended up here :)
It seems that DeploymentItemAttribute doesn't support using the same source path name in multiple test classes.
Note: I said same path name, not physical folder (think different test projects with same folder name to deploy).
However the destination folder name can be different, with no ill effects.
My suggestion is:
Create a fixture base class (if you prefer, in separate project)
Add the attribute: [TestClass, DeploymentItem("LanguageData", "LanguageData")]
Change your OcrTests and OcrBuilderTests classes to inherit the new class.
Remember to remove the deploymentitem attributes for 'LanguageData' from OcrTests and OcrBuilderTests
I've tried this, with Great Success.
In my case, I had a common test fixture project and multiple test projects, each using the base class.
Unfortunately the DeploymentItemAttribute is filled with Gotchas, see here for more.
Tried your approach but still it did not copy folder properly, so what i did instead copied files not directories(maybe this helps someone):
[TestClass]
[DeploymentItem("connectionStrings.config")]
// should be able to do this, but it does not work always, only sometimes
//[DeploymentItem("Configs", "Configs")]
// this instead should work always
[DeploymentItem("Configs\\file1.txt", "Configs")]
[DeploymentItem("Configs\\file2.txt", "Configs")]
[DeploymentItem("Configs\\file3.txt", "Configs")]
.....
[DeploymentItem("Configs\\filen.txt", "Configs")]
public class BaseTests
{
}

Resources