With the inclusion of Microsoft Fakes in Visual Studio 11, I thought it would be worth to look into again, since I did not find Moles mature enough last i checked. The documentation is still sparse, but I cannot find any reference to mocks, i.e. the ability to set up and verify expectations on the faked objects.
Does anyone know if this is currently included (as a feature in the library) or will be?
It is not included currently, but we are considering something in this area.
Although they are not included, you can use stubs to hack in the same behavior. In your stub you can capture whether the method was called and the parameters that were called. Of course, by the time you start doing that you're almost hand rolling your own mocks.
In the meantime I'd suggest Moq or RhinoMocks. I find the syntax simpler and I'm not a fan of the generated code that Microsoft Fakes uses anyhow. Try renaming a method on one of your fakes using a refactoring tool. It's not possible because your fake is a generated class, not an instance of the interface you are stubbing.
Related
Can anybody explain how can i call .net methods(from .dll) in my java code but i dont want to write/use C/C++ Code please expalin it Step by Step
You haven't given us any information to work off (How large are the two projects? Are you forced to use a specific CLR/JRE? Can they be two separate processes or do you just need to access a bunch of methods? Stuff like that), but I can point you in a general direction...
IKVM.NET is an implementation of Java that runs on the CLR. If you run your Java program in there, you can interop with any other .NET language easily.
If you can't use this for some reason, then you're probably going to have to embed Mono in your application and write some JNI bindings to start an instance of the CLR, then load and invoke your code.
If you've got a small amount of methods, consider just porting the code to Java instead of creating this huge system in order to get a small amount of functionality.
I can't explain it step by step because you haven't provided very much information as to what restrictions you have or how it needs to be done. Also, this isn't something trivial. You're trying to get two language runtimes to interact with each other without using native code, when native code is the only thing either runtime can interoperate with.
I have developed a number of frameworks that I want to ship with my application. I don't want others to be able to use the frameworks, but i've seen utilities such as class-dump which can get the headers back easily.
My question is, how can I make my frameworks more secure? I know that they'll never be 100% secure, but are there some good general tips to follow?
Thanks!
In short, don't bother. The very nature of the Objective-C runtime is that there is significant metadata available.
The reality is that it would be exceedingly rare for someone to pick up your framework and try to embed/use it.
Note that code obfuscators don't really work very well; there is still quite a bit of metadata that must be exposed. You can go that route, but -- generally -- it makes debugging/crash analysis significantly more difficult without actually solving a real problem.
I see others have pointed you down the path of obfuscation (though I suspect that the answer of #define someSelector mmmrrrggglll wasn't really tested much).
Some specific points to consider as you go down this path (I'm sure I've missed many):
if you use KVO/KVC, make sure you obfuscate all those calls to addObserver:* and the like
if you are targeting Mac OS X, don't forget about Bindings, too!
Interface Builder's xib files will often contain references to instance variables and/or properties and/or methods. Don't forget about those!
Anything that uses runtime introspection will need obfuscation, too.
make sure you don't obfuscate anything that the system frameworks are dependent; wouldn't want to subclass NSView, say, and then obfuscate drawRect: or initWithFrame:.
In some cases, the Info.plist can refer to class names and entry points. Don't mess with those, either!
Also, make sure every use of #selector() is also properly obfuscated; nothing like setting up an NSTimer firing against a method that no longer exists.
Make sure your obfuscation plans also includes the engineering work necessary to create an un-obfuscator for crash logs.
You'll also want to consider how you are going to debug a production binary; assume your stack traces will be obfuscated. b mmmrrrggglll ftw!
If your framework has symbol exports control, make sure to obfuscate 'em, too! Keep in mind that the way symbols are created differs between architecture and compiler, in some cases.
You can use static libraries to link with your application instead of frameworks. However, if you want to ship frameworks, you can use code obsfucators to make your library more difficult to use.
EDIT:
This SO post has a pretty simple description of a basic obsfucation.
How can objective C classes be encrypted
There are products on the market that do this, but they are expensive.
I've been learning about DynamicObject in .NET 4.0 and was wondering if this type would be well suited to creating mock objects.
Mocking seems like a great way to use DynamicObject, but am I missing something?
Are there any mocking frameworks that use DynamicObject (as opposed to dynamic proxies or interception) for mocking?
Are there any disadvantages to using DyanmicObject for mocking (besides requiring the .NET 4.0 CLR)?
The biggest drawback that I can think of is that you can call literally any method/property in the world on a dynamic types.
for example, think of the hell it would be to update your tests if your api changed - you tests would still all compile, however they would all die with runtime errors if they tried to exercise the renamed/removed methods.
This, combined with the fact that you lose all Intellisense when operating on dynamic objects leads me to believe that a dynamic-based mocking library would be more difficult to use that something proxy-based like Rhino.
This answer to a question about C++ unit test frameworks suggests a possibility that had not occurred to me before: using C++/CLI and NUnit to create unit tests for native C++ code.
We use NUnit for our C# tests, so the possibility of using it for C++ as well seems enticing.
I've never used managed C++, so my concern is are there any practical limitations to this approach? Are many of you doing this? If so, what was your experience like?
We do this all of the time. We have many assemblies written with C++/CLI and use C# and NUnit to test them. Actually, since our goal is to provide assemblies that work well with C#, doing this makes sure that we have accomplished that.
You can also write NUnit tests in C++/CLI and call unmanaged C++. Probably the best way is the keep your pure unmanaged C++ in a lib, and then make a test assembly that uses NUnit and links to the lib.
It works very well and gives you the benefit of having parameterised tests as well as a common test runner and framework if you're in a mixed environment.
There are two downsides, neither of which is serious for most cases:
If you're being really picky, the tests are no longer being run in a purely native environment so there's an outside possibility that something may work under test but fail at runtime. I think you'd have to be doing something fairly exotic for this to matter.
You rely on your C++ code being able to be included into a C++/CLI program. Sometimes this can have clashes with headers and it forces your code to build OK with UNICODE. In general, this is a good thing as it uncovers crufty bits of code (like inconsistent use of Ansi variants of Win32 calls). Bear in mind that it's only the headers being included so what it may well show is that you are exposing headers at too high a level - some of your includes should probably be within your cpp implementation files.
My experience is that it is not possible to use NUnit to test C++ native code through C++/CLI because you will have trouble loading and using native code.
I have tried using nunit to load a basic c++/cli test dll linked against "just thread" which is an implementation of the c++ standard thread library.
Test dlls won't even load with the latest version of NUnit (2.6.2).
So definitely not the way to go!
I never used one, but isn't there a port? Perhaps http://cunit.sourceforge.net/documentation.html would work for you.
The biggest concern is the learning curve of the C++/CLI language (formerly Managed C++) itself, if the tests need to be understood or maintained by non-C++ developers.
It takes a minimum of 1-2 years of C++ OOP experience in order to be able to make contributions into a C++CLI/NUnit test project and to solve the various issues that arise between the managed-native code interfaces. (By contribution, I mean being able to work standalone and able to make mock objects, implement and consume native interfaces in C++/CLI, etc. to meet all testing needs.)
Some people may just never grasp C++/CLI good enough to be able to contribute.
For certain types of native software libraries with very demanding test needs, C++/CLI/NUnit is the only combination that will meet all of the unit testing needs while keeping the test code agile and able to respond to changes. I recommend the book xUnit Test Patterns: Refactoring Test Code to go along this direction.
Since HTA applications are hosted within MSHTA.exe how does one provide a manifest? Plus I assume providing a MSHTA.exe.manifest could potentially break other HTA apps?
On Vista+, MSHTA.exe has an embedded manifest, which takes priority over external manifests, so your suggestion is not an option.
On XP/2003, yes, your suggestion would work, although it would be bad form, as is dropping files in System32 to modify the behavior of a system binary (especially make sure that any registration you put in the manifest are objects you are the only one to care about).
The proper solution, available on Win2003 and above, is to use the Microsoft.Windows.ActCtx object to instantiate your object given an explicit manifest reference.
For example:
var actCtx = WScript.CreateObject("Microsoft.Windows.ActCtx");
actCtx.Manifest = "myregfree.manifest";
var obj = actCtx.CreateObject("MyObj");
Perhaps, if this must work on XP as well, a path you may take is a combination of both solutions.
Edit: My answer is wrong, but I'll leave it here to avoid any similar wrong answers :)
If you question is can you access a COM object without registering it on the machine, then I think the answer is a tentative yes. However the work you would need to do would be substantial and would mean implementing a lot of the low level code that most development tools provide for you as a matter of course (Delphi, .NET, JAVA). You would need to interface with the dll directly (like you would a normal dll ), query its interfaces and call your methods.
If you have C, C++ knowledge, the way COM is accessed from these languages would give you some pointers.
Sorry I cant be of any more help.