Develop Reference

What to use when creating a stand alone app from a web app?

I was asked to create a stand alone application from a web app - I have to keep the same look and feel and of course the functionality. Basically, the end result should be the following: a standalone product that looks and does exactly the same thing as its web - based counterpart.
I have been developing for some time with asp.net and c#, but I doubt this is easy to convert to a standalone C# application.
I heard some stuff about xaml - but I am not sure what to use to make my life a little bit easier.
Should I just leave the .Net platform and turn to Java? Or if I keep the .Net what should I use?

better to keep in .net as it would be easier to migrate the code.
and .net is better than java in terms of desktop apps.

Web and desktop apps are fundamentally quite different (as much as ASP.NET Web Forms developers would argue to the contrary), but you should be able to reuse a lot of your business logic (especially if you separated your concerns properly). I'd suggest starting with a new Windows Forms project, building out an equivalent set of controls (buttons, grids, etc), and then looking for opportunities to borrow UI logic (click events, etc).

If your web app is written in ASP.NET, then I would stick with that.
If your web app was built properly and the new app has to have the exact same functionality, then you should be able to re-use most of the code whether you use WPF or Windows forms. You would just need to rebuild the UI.

Keep the .Net code and see how much you can reuse. Tell that you can't make the user interface look and work exactly the same and that there will be a lot of minor and some major differences. Add that the look and feel will be the same with added functionality.
See if you can reuse the basic data loading code. Then simply create a form/panel/tabpage for each page in the web application and see what you can reuse.
Or easier yet, create a simple windows application using a browser window and simply point to the existing app.

Advice on MVC pattern for WinForms app

I'm writing a Windows version of my Mac app (C# Winforms) and would like some advice on what design pattern to use.
My Mac app uses an MVC pattern with Core Data for storage. This is a simplified diagram of the models and relationships:
The desktop app collects logs on a background thread and periodically uploads them to my web app. The database is used to store both the user's account information and logs, and the app has a 3 views to display (and collect) the user's data.
I've done some reading and it seems that MVP is the recommended design pattern for WinForms apps, but I'm not sure how to proceed from here. I think that my app is simple enough to write without using an external framework like MVC# but as I have never made a WinForms app before I am only speculating.
Can someone recommend the best way to go about this?

Patterns are really just guides as to what problem it is trying to solve. Where an MVC would work well for a web app that relies on pages and redirects etc a winform app can benefit from using MVP.
Having said that the two patterns are siblings of a wider UI pattern and even according to Martin Fowler the MVP pattern can be further split. Look at his article to get a good feel for the appropriate pattern. He has broken the MVP to Supervising Controller and Passive View. Even the new MPF MVVM pattern is actually based on the PresentationModel pattern.
I would say look at the patterns and see what fits rather than trying to use a pattern because you used it in another scenario.

In my experience for a winforms application (which supports nice databinding) you can use MVC with a supervising controller pattern. Read through this question What are MVP and MVC and what is the difference? & http://codebetter.com/jeremymiller/2007/05/25/build-you-own-cab-part-3-the-supervising-controller-pattern/

You should take a look at Jeremy Miller's Build your own cab series :
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/

Start to work on it, do some screen mockups, do some design, write some code.
You could start with a few small prototype, try out different design. Don't go too far in your exploration phase so that you don't hesitate to throw it away and start over if you need.
Try to keep your choice open as much as possible, don't paint yourself into a corner, and delay this decision until your really need to choose one way over another.
By then you will probably have a much better Idea of what you need.

What's are the best readings to start using WPF instead of WinForms?

Keeping in mind what CannibalSmith once said - "All the answers are saying "WPF is different". That's a huge understatement. You not only have to learn lots of new stuff - you must forget everything you've learned from Forms. It's a completely new way of doing UI."
.. and having many years of experience with visual Windows desktop applications development (VB6, Borland C++ Builder VCL, WinForms) (which is hard to forget), how do I quickly move to developing to say well-formed WPF applications with Visual Studio?
I don't need boozy-woozy graphics to give my app look and feel of a Hollywood blockbuster or a million dollar pyjamas. I always loved tidiness of standard Windows common controls and UI design guidelines, end even more I enjoyed them under Vista Glass Aero Graphite sauce.
I am perfectly satisfied with WinForms but I want to my applications to be built of the most efficient and up-to-date standard technologies and architectured according to the most efficient and flexible patterns of today and tomorrow, leveraging interface-based integration and functionality reuse and to take all advantages of modern hardware and APIs to maximize performance, usability, reliability, maintainability, extensibility, etc.
I very much like the idea of separating view, logic and data, letting a view to take all advantages of the platform (may it run as a web browser applet on a thin client or as a desktop application on a PC with a latest GPU), letting logic be reused, parallelized and seamlessly evolve, storing data in a well structured format in a right place.
But... while moving from VB6 to Borland C++ Builder was very easy (no books/tutorials needed to turn it on and start working) (assuming I already knew C++), moving from BCB to WinForms was the same seamless, it does not seem any obvious to me how to do with WPF.
So how do I best convert myself from a WinForms developer into a right-way thinking and doing WPF developer?

Read this questions:
How to begin WPF development?
Is there a WPF Cheat Sheet outhere?
Learning MVVM for WPF
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
Download and work through this Microsoft tutorial: Southridge Hands-on-Lab
Check this videos:
Mike Taulty's series of videos
Jason Dolinger on Model-View-ViewModel
And after that, take a look at StackOverflow questions tagged with both wpf and mvvm

Keep in mind that MVVM seems suited only to single window applications.
I dived into WPF based on inexperience and general recommendations that it would suite better a kiosk project, especially one where the customer has given me photoshop images of all the application screens. Having cool graphics was a requirement for this project and I liked the vague resemblance of WPF with web development.
I found out a few downsides
1) there is no such thing as an official MVVM toolkit. There are a lot of them, all backed by an individual. A shot at a toolkit by Microsoft has been put on the back burner one year ago and there is no VS2010 support.
2) programming a multi windows application, sort of a simple wizard with back and forward, is plain nightmare. I got out of this with a clean design defining a delegate for each UI action and a command for each business action, but still I think it is too much involvement with a framework to be justified, and you cannot show the result of your tests to this customer expecting excitement.
3) You give up the habit of double clicking a button and adding some code. This leaves a nagging feeling of using the IDE against its nature. Basically you use Visual Studio as a text editor and an interface designer, still with a great help from the tool.
The upsides, so far are:
1) defining visual components is very flexible, fast and easy and you can choose between VS and Expression Blend. Animations are simple to create.
2) data binding simplifies the application. You define a DataContext and bindings and do not have to move data from the business logic to the interface yourself, as long as you have a property for everything that must be displayed.
3) You can reduce the amount of business logic in the interface to zero. It is easy to separate the application behaviour from its looks, so you can skin your interface in ten different ways with little effort and test all of your logic without opening a window.
4) you leave a door open to going with Silverlight if they ask you.
My conclusion is that if you have an MDI application in mind you might find yourself in big trouble. You should be aware that, if you choose WPF, you are ploughing ground for future generations rather than getting on a train that will get you there fast and easy. There is no established way to do things, especially those that are not covered by demos.
Toolkits, all things considered, are not so important and each of them will serve you well. In fact a couple supporting classes are enough to start and there are no fancy wizards, it is up to you to follow conventions.
You might even make your own if a few hours, once you understand what is involved in the logic. The downside is that you will have to really understand it well to bend the application your own way.
As I said above, I had to learn a lot just to show a new view when they click a button keeping the code clean. Take the time to see the videos cited elsewere on StackOverflow it will save you time.

if you are looking for books just look at this previous post
What WPF books would you recommend?

Having got into WPF this year, the most important thing for me was learning how to use the Model View View-Model pattern for separating the view from the app logic. As a general rule of thumb if you find you are placing a lot of code in the code behind for your view then you are "doing it wrong".
I found that coming from a WinForms background I was putting in lots of event handlers and doing stuff in my code behind. As I became familiar with MVVM and WPF features I found I was able to remove the bulk of my code behind and replace it with views binding to view-models.
It was articles like this one from Josh Smith that helped get me started on the MVVM path:
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
Once you have started to get the hang of displaying data view MVVM bindings, have a look at commands and specifically the ICommand interface. They are the main mechanism by which actions from the user triggers operations to execute. So rather than having a OnClick handler for buttons, you bind the Command property of the button in XAML to a property in your view-model that exposes an ICommand implementation.
My 2c - Donovan

Try this smashing hit.
Windows Presentation Foundation - Unleashed By Adam Nathan
(source: adamnathan.net)

Is there any framework for Windows Forms, DB driven application development/prototyping?

I'm writing simple database driven application, 80% of functionality is CRUD operations on about 15 tables.
Coming from web development background I figured I can cover almost all of these CRUD cases with Rails scaffolding or say Django admins.
So I started to look around for Rails/Django-like framework but for Windows Forms applications (ofcourse I understand that "rich client" application
development significantly differs from a web development and I'm not expecting anything really similar).
I was surprised that except for a variety of ORMs (let's call it Model-layer) it seems like I'm left with little choice
when it comes to View-Controller layer. Maybe I'm missing something?
PS. I evaluated Visual Studio DataSet Designer, but it seems to work only for the most simple cases, and requires additional code for any slightly nontrivial task.
(added) so far I've found:
TrueView for .NET (thanks to Vijay Patel)
NConstruct

I would start to look at the Entity Framework if you can use .net3.5
Introducing the Entity Framework
How to: Bind Objects to Windows Form Controls (Entity Framework)

You could try DevExpress eXpressAppFramework. If I've understood you correctly it should do what you're looking for. It works with Winforms and ASP.NET and also has an accompanying ORM framework. There are some videos here that demonstrate the product. And there are forums here if you need to ask specific questions.

Did you check Rocket Framework for Windows Form
Everything is perfectly in order to support your requirement.
This use Entity Framework as the back-end
Use Object Data Source to Auto-Bind Object to UI
Use Generic to minimize the amount of code you need to write
Additionally, the documentation also is very well done and architecture is pretty good and stable too..
I am using it right now and it is serving me pretty well

As far as I know MVC framework for Winforms don't exist. I've thought about it but I think it would just get too constricting no matter how hard you tried. The fact you're not tied to a single page in a browser just completely throws alot of standards out the window. According to your needs you can have a single MDI form that would be similar to the web and web ideologies would be applicable, or you could have an MDI form that could be filled with MDI forms and standard forms and they could need to talk to each other to make sure they're up to date, even in the background which isn't an issue in webforms.
At the same time threading becomes a huge issue as a half a second wait on the web is nothing while if a program freezes for even that long you have problems. There are even more approaches to threading than there are to the MDI/Form Design issue.
I've almost always lived in the WinForms world and I tend to start with a VERY generic MVC implementation and let it evolve as needed to meet the current needs. I've yet been able to apply an entire previous implementation in a greenfield project.

Shameless plug: You could try our TrueView for .NET framework.
It's based on Domain Driven Design and the Naked Objects pattern. It provides an auto-generated 'explorer' style UI at run-time (no code generation step), but you're free to override forms with your own implementations.

What is the API to the database you will be using? If it's a SOAP web service you could use the Microsoft Smart Client Factory at CodePlex. If it's a local SQL Server database you should consider Entity Framework.

DataSets based .NET programme: Use Designer tools or do it self?

After thinking for long, I have decided to build my data app for the Not-for-profit organization I work for (I don't program regularly there, though...) using C#, .NET 3.5 (using ADO.NET DataSets) and Scimore db.
I have done base basic tinkering till now and have found this combo to be quite good and fast. Ya, "fast" is a requirement for me, as our computers are slow.
I have a question though: should I use Visual Studio design tools to help me build my GUI for data bound controls or should I code them by hand? In simple scenarios, I have found that designer generated code seems to be too big for the purpose.
Will it somehow affect the "fastness" of my final app?
Thanks for reading!
Edit Sorry, I didn't mention, this would be a desktop application, using Winforms

Usually the amount of code does not affect execution speed so I shouldn't worry about that. Therefore, you should consider using the Visual Studio design tools for building your GUI. Most of the time you can build your application a lot faster this way.

if you're looking to keep your ASP.NET code as lightweight and fast as possible you may want to look at using ASP.NET MVC. This is the technology used to create StackOverflow, it gives you a lot of control over which data technologies you want to use to implement your site, and it for the most part avoids the overhead of using ASP.NET server controls. You may find this to be a great option for your needs.