Based on all of your feedback and some additional search I have the following solution for me I will return a Transaction-Object struct TransactionResult { double amountReturned; EnumTransactionResult eReturn; } Some more info: - I have no complicated scenarios as "Pending Transactions" - Of course: I can overdraw the account upto an allowed value, which can be less than zero - This fully fulfills my use-case Thank you for your input. My question is fully answered

Maybe try a newer version (3.9): [Downloads](http://nunit.org/download/) "(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal

It's me again. I created my first asp.net-site, following this link Building your first MVC 6 application — ASP.NET MVC documentation[^] I have no problem with the "Model-View-Controller"-Pattern, but: a) I am intimidated by this enormous bunch of tools I had to setup before the project was built successfully b) there is an endless number of files generated which tells me nothing Finally: I am sure, nobody in this world is able to understand what's going on here :-)

You do realise that Silverlight has a sunset date of 2020 and won't be supported in the newer browsers! Do some research into WCF although you should be getting your data from the MVC component. Weird setup, I've never heard of this structure being used! Never underestimate the power of human stupidity RAH

OK. So what exactly is your question then? There are only 10 types of people in the world, those who understand binary and those who don't.

you are welcome. :-D நெஞ்சு பொறுக்கு திலையே-இந்த நிலைகெட்ட மனிதரை நினைந்துவிட்டால்

I've been using CruiseControl.NET for around 4 years and it does everything a CI server needs to do, and it works well with the .NET Framework as you'd expect. It runs all our builds without any problems, including our deployments. It's easy to install and configure, and there is large community to help you support it. Do you have specific requirements? "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare

Not sure why this is downvoted? Perhaps it was very bad pre-edit. Anyway, what you are asking for is a classic plugin architecture, and that's a well solved problem. There are three steps to it: Create a boundary interface that defines what the plugin should do. This interface should be in an assembly available to both the plugin developer (plugins need a compile time reference to the assembly) and the application. In the case of a releasable app or something where the same team develops both sides it can go in the main application assembly. Create plugin classes which implement the interface and do the work. Write some reflection code in your main application that finds instances of the plugins in relevant assemblies, and registers them. The exact implementation of that depends on whether you need AppDomain separation between plugins (for example if you want to support plugin update or unloading without restarting the application, or different security contexts), and whether plugins will be in separate assemblies. In this case the boundary interface is public interface IReportGenerator { void Validate(); void Execute(); } ... although I'd expect some form of input to be passed to both methods in reality. The simplest version of the reflection code (look in a single assembly only) looks like this: public void RegisterPlugins(Assembly a) { foreach(Module mod in a.GetLoadedModules()){ foreach(Type ty in mod.GetTypes()){ foreach(Type intf in ty.GetInterfaces()){ if(intf == typeof(IReportGenerator)){ RegisterPlugin((IReportGenerator)Activator.CreateInstance(ty)); } } } } } For a full implementation including looking up assemblies in a directory and loading each plugin into an AppDomain, check out my game lobby article[^] (LobbyClient/GameType.cs or LobbyServer/GameTypes.cs). Although don't necessarily copy the coding style in there, that is old code from before I knew what I was doing.

...for the moment.... thank you for your kind replies

A bit hard without the ability to embed an image, but I'll try: /*********\ * * * state 0 * * * \*********/ | ^ ^ | | | v no| |yes / \ | | / \ | | R==1?>-+ | \ / ^ \ / / \ V / \ | <R==0?>-+ | \ / | |yes \ / no| | V | | ^ | | | | v | | /*********\ | * * | * state 1 *<--+ * * \*********/ Ok, the readability suffers a bit - sorry for the bleeding eyes ;) GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Jasmine2501 wrote: It is absolutely correct and you are wrong You are wrong. Jasmine2501 wrote: and that is absolutely annoying and it would be to anyone Again that is an emotional context which doesn't interest me and has nothing to do with the technical merits. Jasmine2501 wrote: Seriously, let it go dude, nobody cares any more. And yet you keep responding and keep claiming that I am wrong.

Great links - thank you

This is a problem with NUnit itself? You should raise it as an issue here[^]. *pre-emptive celebratory nipple tassle jiggle* - Sean Ewington "Mind bleach! Send me mind bleach!" - Nagy Vilmos CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Frygreen wrote: Do you have any idea? No. Frygreen wrote: Sorry,for Whitespace. Frygreen wrote: (built .net4.0)with Grammar. Whitespaces are not an "english-only"-thing. Frygreen wrote: Verything Grammar. Please read the text before posting it. Frygreen wrote: I get an exception from NUnit and I can not see any code as expected Add the exception message. Without it there is anyways no one who could answer your question no matter where you post the question. The more details you give the better are the answers you receive. "There is a difference between love and just living together because you'll get serious problems otherwise (eg because her father would show up with a shotgun if I'd move out :WTF: ) :-\. However, I respect JavaScript as a language which is very important to webdevs. But I ain't gonna love it." - That's what I said.

Thank you for your first replys. I got some ideas. But, of course, more replys are welcome :-)

There are some software design practices available, some of them are related to the industry that the applications are designed for, for instance there are specific IEEE standards the apply to medical devices. As for standards specific to documentation I'm not familiar with any standard, as long as the software practices are applied correctly. However a good luanching point would be a site such as the IEE computer society. Here they provide some good information. http://www.computer.org/portal/web/swebok[^] The FDA also provides some guidance as to what should be documented for software requirements and design descriptions. Here is a link to a pdf file from the FDA: General Principles of Software Validation[^] Cheers! It was broke, so I fixed it.

My topic is independent of embedded. How do all the .net - guys here "detailed-design-documentation"? I remember now after 20 years of SW-development, that I never have seen any line of text where it is writen how to structure a design-document. I have many books on how to structure architecture instead. regards

Marc Clifton wrote: It's difficult to capture the dynamic nature of relationships and objects with models Is this some form of euphemism here? I know that models have often objected to dynamic relationships with me. I'm not a stalker, I just know things. Oh by the way, you're out of milk. Forgive your enemies - it messes with their heads My blog | My articles | MoXAML PowerToys | Onyx

So, you have a requirements matrix then with readily identifiable markers? In which case, your testing is based around ensuring that you have satisfied the elements in the requirements matrix. Typically, you would do this by identifying the requirements that are in scope, in your solution, out of scope, not applicable. You also need to identify what parts of the system are affected by the requirements (hence the matrix), and mark these off using the criteria I've just laid out. Now, you know what is in scope and what is out of scope, you should be able to start mapping out what needs to be delivered in what order. I like to use a tool such as Enterprise Architect to link requirements to Use Case documentation, which will indicate what requirements are being satisfied. The traceability matrix you produce is a useful tool for your testing teams because they can ensure that the delivery is satisfying the requirements. This is a huge area, beyond the scope of a simple forum discussion, and it's why a company pays a good BA a lot of money; they take this type of thing in their stride. I will say that a good BA is a must; they will save you from falling flat on your face. I'm not a stalker, I just know things. Oh by the way, you're out of milk. Forgive your enemies - it messes with their heads My blog | My articles | MoXAML PowerToys | Onyx

IMO your balance does not lie in one or the other nor between them, its both. I have seen teams of analysts get lost in reams of requirements, which doesn't get you to the final product, I have also seen scope creep that was bigger than the original project. You need to document the requirements in a hierarchical fashion so you can keep an eye on the requirements and their progress at various levels, keeping an eye on the high level stuff is vital to ensure good direction, but the detail must be available. I don't think going beyond 100 or 200 requirements is practical (as you are then at risk of analysis paralysis) but I suppose massive projects could justify that. (People tend to think more is better and they add more of the same) Try to get a concise list of requirements, at the highest level probably 5 items or so, and make sure you have enough requirements for clarity of each item (in as many levels as needed) but not too many items that will cause people to get lost in the labyrinth... I have seen countless customers who have 600 page process flow documents and no one (I'm not exaggerating, NO ONE) ever reads it again. Also separate functional requirements from technical requirements. Technical requirements can be many, but a product with more than 100 functional requirements is brave. I recon most ERP systems on earth today can be described in about 100 functional requirements or less. I can go on, but its too early in the morning for that... :) --EDIT-- I haven't mentioned testing, but it should be do-able at every level ____________________________________________________________ Be brave little warrior, be VERY brave