The web application was hosted on a dedicated server that was accessible locally, or from intranet or over internet. the IP could always be requested in the way I explained some post earlier. However, this was a long time ago, on a different .NET version that today's. Hope that helps...

-^-^-^-^-^-^-^- planetgeek.ch

Check the "create XML documentation file" and provide a path for the docu file in the project settings. Copy your dll and the docu xml together to your other project.

-^-^-^-^-^-^-^- planetgeek.ch

About NMock / NMock2: the version at nmock.org (NMock) is not actively supported anymore. If you are looking for the latest version based on NMock then have a look at https://sourceforge.net/projects/nmock2[^] (NMock2) Happy mocking Urs

-^-^-^-^-^-^-^- no risk no funk

Think about readablility of your code. In certain scenarios it is better to not use var because of readability: var myVariable = SomeMethod() This is far harder to read than int myVariable = SomeMethod() Without moving the mouse over myVariable or the method and letting visual studio tell me the type in a tooltip, of course.

-^-^-^-^-^-^-^- no risk no funk

Mycroft Holmes wrote:

instead of closing the dialog from the parent just hide it

Why not closing it? Whether you close it or just hide it, you can access the property on the form in both scenarios:

MyDialog dialog = new MyDialog();

dialog.ShowModal();

var someVariable = dialog.Choice;

-^-^-^-^-^-^-^- no risk no funk

You're right, if it is a simple data-only field, it should be simple. But in my experience, it is very seldom a data-only field (at least at the end when the customer says: "Oh, I thought it was clear that this and that business rules has to be changed because of that new field"). The result is some more iterations ;-)

-^-^-^-^-^-^-^- no risk no funk

The real problem here is that most clients think that a simple new field is something trivial to add. But it's not because: - How should it be presented in the UI (UI Layer) - Do the validation rules checking the consistency change (Logic Layer) - compatibility with old data (Logic Layer, DB Layer) - Persistency impact (behavior of database, growth, indices, replication, transfer to data warehouse) (DB Layer) And propably some more...

-^-^-^-^-^-^-^- no risk no funk

With most OR mappers this is a change in the configuration file. Yes, yes I know, if you have performance optimizations in your code, then it's not that easy ;)

-^-^-^-^-^-^-^- no risk no funk

We organize our projects normally in this way: 1) One solution for all projects we are currently developing. Developing with several solutions at once is very cumbersome. 2) However, if there are components that can be extracted in some sort of library or framework then do it (only feasable for components that can be developed independently for the most part, because of 1) 3) If our system is built up from different "sub-systems" (sometimes there is a relationship with tiers, but it's possible to have either several sub-systems per tier or viceversa) then we arrange them within solution folders (note that solution folders are virtual folders and that there are no folders in file system for them). 4) We try to keep the number of projects limited because a large number of projects has a negative effect on build performance. Therefore we wouldn't arrange our project the way you suggest in your post (propably). Keep in mind that assemblies are a deployment unit, nothing else. There is no problem in packing several components into a single assembly, as long as they are deployed together. Requirements on releasing individual components can however be a reason to seperate components into different assemblies. 5) For each project we habe an additional unit test project to seperate the tests from production code. We use a naming rule: for project MySystem.MySubsystem.MyWhatever.dll exists a MySystem.MySubsystem.MyWhatever.Test.dll. This simplifies out NAnt script for building, testing and releasing our software. 6) Namespaces are hierarchical and should be used in this way. That means that we express abstractions with namespaces. E.g: MySystem.MyComponent contains everything that is used in that component and MySystem.MyComponent.MyImplForCaseX contains the details for a specific extension while the code in the subnamespace can access the content of its parent namespace. This results in very little access to sibling or child namespaces, thus supporting loose coupling of components. 7) We use subversion as version control system. With the following structure (this is however really project specific): root/ trunk/ doc/ source/ libs/ contains all 3rd party dlls our projects reference, built up with svn-externals and real dlls scripts/ contains all NAnt scripts for building, unit testing and releasing tools/ tools used for building etc. releases/ Release 1.0/ [trunk/] only if release is modified (bug fixes)

I suggest using a dependecy injection container (Unity Application Block, Castle's Windsor Kernel, Spring.NET). Then you have only one single global variable, the container itself. All other global variables will make unit testing, decoupling of components and maintenance a great bit more difficult. Happy coding Urs

-^-^-^-^-^-^-^- no risk no funk

You may also consider the "interface segregation principle": One possible link to find information: http://www.objectmentor.com/resources/articles/isp.pdf[^] You find a lot of hits with google about it, too.

-^-^-^-^-^-^-^- no risk no funk

You have to click the Button on the same thread as it was created, otherwise you'll get this exception. For normal applications that means that all UI components are created on the main (UI) thread and all calls to the UI coming from background threads have to be marshaled back to the UI thread, either by using Control.Invoke or a SynchronizationContext. In your szenario, either run the 3rd party software on the UI thread and your tasks on a background thread, then you can use Invoke or a SynchronizationContext, or really be sure that everything you call to the 3rd party app is on the same worker thread. Regards Urs

-^-^-^-^-^-^-^- no risk no funk

In C# (and VB.net as far as I know) you do not have seperate header and implementation files. You have only one (e.g. .cs on C#) for normal code. This file contains for example the class with its interface and implementation in one place. There can exist several files when classes are marked partial (normally used for classes that are partly auto-generated). regards Urs

-^-^-^-^-^-^-^- no risk no funk

In your foreach loop: 1) p is a PropertyInfo of Type t 2) you call p.GetValue with an instance of type MyProperty, which is probably not of type t Therefore the exception. You should call GetProperty with the instance from the controls collection, where you get the type from. regards Urs

-^-^-^-^-^-^-^- no risk no funk

We solved a similar problem by using a mapping from DayOfWeek to integer that returned 7 instead of 0 for Sunday. This way your code would work, too. Not very nice but it works. For .net the week start on Sunday :(

-^-^-^-^-^-^-^- no risk no funk

Why do you declare

girijaa wrote:

public class ScheduleVOMapper: BaseVOMapper

and not FlightVO instead of BaseVO as generic parameter? I couldn't test it right now, just guessing. Urs

-^-^-^-^-^-^-^- no risk no funk

What do you do in your worker thread? If you have something like a while(...) { do something } then you can loop until a signal (e.g. a AutoResetEvent) is set by the main thread. Urs

-^-^-^-^-^-^-^- no risk no funk

Application.Exit will never terminate the process. Normally you have something like this in your winforms app:

public void Main()
{
MyForm form = new MyForm();
Application.Run(form);
}

Application.Exit will cause that the Application.Run method returns to the Main method and then, of course, the process will end, because nothing is done afterwards. best regards Urs

-^-^-^-^-^-^-^- no risk no funk

Do you use project or file references for your projects in your solution to reference each other? Project references are preferable. Just a guess though :)

-^-^-^-^-^-^-^- no risk no funk

I just wanted to add that - foreach loops the same way as you would probably yourself with a for loop (nothing strange about it, really) --> keep the foreach, because it is better readable - Focus should work, to debug the problem, try to have a look at the ActiveControl property of your form or user control to see, which control has currently the focus and whether that control has a validate method that prevents setting of the focus to the button. Urs

-^-^-^-^-^-^-^- no risk no funk