>>>>>>>>>Hi,
>>>>>>>>>
>>>>>>>>>I suppose that someone here has a beta version of VS 2010. Does VS 2010 include WinForms projects?
>>>>>>>>>
>>>>>>>>>Also, if you install VS 2010 on the PC that has VS 2005 can you use either independently? That is, can you still maintain VS 2005 projects with VS 2005 after installing VS 2010?
>>>>>>>>>
>>>>>>>>>TIA.
>>>>>>>>
>>>>>>>>Yes, although VS 2010 marks the more or less official blessing of WPF over WinForms.
>>>>>>>
>>>>>>>Thank you, Mike. This is exactly why I want to get VS 2010 so I can start learning WPF. I still want to continue working in WinForms for immediate future.
>>>>>>
>>>>>>WPF is also in VS 2008, so it is possible to learn and use it without VS 2010. If you are starting fairly fresh, as I believe you are, WinForms is to an extent going to be throwaway knowledge. Personally I am not crazy about that because it is a much more familiar paradigm than WPF. And I hate XAML!
>>>>>
>>>>>Using WinForms requires great deal of learning of ADO.NET and C# so it is a wasted time only if WPF no longer uses C# or ADO.NET. Right?
>>>>
>>>>As for learning and being productive while you learn, a great deal can function if put in either XAML or in the code-behind. Does it belong there? Most likely not, but in some cases Yes. This is a simple example of how animations could be done in either place, but it proves the point and also at the very end of the (very short) article, includes a good statement as to which code goes where:
>>>>
>>>>Short and sweet:
>>>>
>>>>XAML - design, code behind business logic.
>>>>
>>>>http://dotnetslackers.com/XAML/re-211780_XAML_By_FARR_Animations_Resources_Vs_Code_Behind.aspx
>>>>
>>>>Even this MSDN article specifies it clearly I think:
>>>>
>>>>The primary application-level mechanism for adding a behavior for an object element is to use an existing event of the element class, and to write a specific handler for that event that is invoked when that event is raised at run time. The event name and the name of the handler to use are specified in the markup, whereas the code that implements your handler is defined in the code-behind..
>>>>
>>>>http://msdn.microsoft.com/en-us/library/ms752059.aspx
>>>
>>>I will follow the links and read them. But are you saying that you write your business code in XAML too? No place for C#? And what about ADO.NET? Do you use XAML to manipulate ADO.NET objects?
>>
>>The business logic always goes in the code-behind (in C# for you) and the design stuff in the xaml. This article does the best job of explaining the separation and presenting different possibilities for good teamwork I've read (seriously):
>>
>>http://windowsclient.net/wpf/white-papers/thenewiteration.aspx
>>
>>note this statement in the article:
>>
>>Choose Code-behind
>>Though WPF allows you to insert code inline with the XAML, this is not a recommended practice. Avoid it at all costs; placing code inside a XAML file breaks the separation between code and XAML, leading to a maintenance nightmare.
>
>I'd take that advice one stage further - don't even put code in code-behind :-}

I think it really belongs in the other layers (is that what you meant)?