Whether we like it or not, unlike conventional engineering structures like bridges and buildings, software will always be engineered and built to be changed at some future point. It is the nature of the business requirements that we are there to serve. Everything changes. Constantly. Software Engineering is the science we busy ourselves with in order ......

---

Suppose I have a stubbed interface acting as a proxy for the real object:IDatabase databaseStub = MockRepository.GenerateStub... suppose I have a parameterized method which needs redirecting to some utility method, for instance to return some test data:DataSet IDatabase.RetrieveData(int entityId);And I have a local utility method ......

---

In this case there is a base class:

struct base {};

and a derived class:

struct derived1:base {};

To test if derived derives from base:

return dynamic_cast<base*>(derived*) != nullptr;

---

So suppose I have:gcroot<SomeObject^> someObjectGCRoot;SomeObject someObjectOnTheStack;And I want to assign the gcroot object to the stack object.The solution is to declare the stack object as tracking reference instead of the raw type. So instead of:SomeObject someObjectOnTheStack;instead declare:SomeObject% someObjectOnTheStack;Then the conversion ......

---

The usual rules for stubbing objects apply: The method has to be public. Generate the stub from the interface and not the physical object to avoid the actual implementation being called.If you want to create a partial stub of an object instead of the interface, the methods you wish to stub HAS to be virtual, or they'll be called as you are stubbing ......

---

We had an issue once we deployed our .Net 4.0 C# ZeroMQ solution to a Windows Server 2008 instance where the application would freeze up or block, seemingly on the initialization of our ZeroMQ library. Upon furthter investigation it was discovered that the application was blocking on the construction of each new zmq Context object. Having exhausted ......

---

Scratched my head with this one a bit, but here is the solution: Obtain the IntPtr equivalent of the char*: const unsigned char* data; System::IntPtr dataptr((int)data); Then use the System::Runtime::InteropSer... class to copy the data into the cli::array<Byte>: array<Byte>^ byteArray = gcnew array<Byte>(dataLength); Marshal::Copy(dataptr, ......

---

It turns out that in order for executable assemblies to successfully link, the simple reference to the managed assembly is not enough on its own. Although this is sufficient for the compiler, the linker also needs to be told where to find implementations. This is done through setting the "Use Library Dependency Inputs" to Yes under Project Properties->Configuration ......

---