Related
Quite some time ago, I implemented a tool for creating and maintaining Work Breakdown Structures in combination with Microsoft Team Foundation Server (you can find it here: http://wbseditor.codeplex.com). It was originally implemented using the TFS 2005 object model, and also relies on the WorkItemFormControl to display Work Items for creation and editing directly from the application. It's quite useful, and is heavily used inside my company for multi-project management.
A while ago, I ported it to using the TFS 2010 assemblies, but now, a couple of years later, I have the need to also support Visual Studio 2015.
In the course of migrating to the new assemblies, I have managed to get all the nuget packages I need (which is Microsoft.TeamFoundationServer.ExtendedClient), but apparently both the WorkItemFormControl (which was targeted for Windows Forms) and the newer WPF equivalent WorkItemControl (from the Microsoft.TeamFoundation.WorkItemControl.WpfControls namespace) are missing.
I suppose I can use a web browser control to achieve a similar effect like before, but I have not found any sample code or similar for this. Does anybody have a pointer how to get a similar effect like I got with WorkItemFormControl? I admit I haven't spent more than a couple of hours on research, simply because I just wanted to do a "quick update" to support the new server versions, and this sort of caught me cold.
Is there a "quick fix" for me I just have been to blind to see?
If there is no such thing as a quick fix, which is the general direction I should head to get the functionality back?
WorkItemFormControl Class is now obsolete, use the WPF version of this control, Microsoft.TeamFoundation.WorkItemTracking.WpfControls.WorkItemControl instead.
To use Microsoft.TeamFoundation.WorkItemTracking.WpfControls.WorkItemControl namespace, you need to add assembly Microsoft.TeamFoundation.WorkItemTracking.Controls which can be added from Microsoft.TeamFoundation.WorkItemTracking.All in nuget package.
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
I'm considering switching from MFC to WPF.
My first concern is that there are too many users who don't have .NET with WPF installed yet. Can anybody point to a source containing the WPF penetration numbers?
My second concern is speed.
Any other considerations?
I've been banging away at WPF for a while now. It is brilliant, but it still has (occasional) holes you've to plug yourself. However all indications are .NET 4.0 will be a significant step forward.
I would say start now. The WPF learning curve is REALLY steep, and it'll be a while before you'll be releasing software to users, believe me. Also do yourself a favour and get the WPF Unleashed book. It's superior.
Speed isn't a consideration. The power WPF gives is well worth any drawbacks with speed, which - coming from Windows Forms - I haven't noticed to be honest.
What kind of application are you developing? If it's a wide-distribution desktop app that you want your grandmother to install, your concern about .NET 3.0/3.5 adoption is valid. So far from what I've seen, performance is less of a concern.
WPF penetration
First of all, Windows Vista and Windows 7 both have WPF preinstalled, which accounts for 35% of the market automatically. Windows XP has had it as it had .NET Framework 3.0 as an option in Windows Update for over three years, and many applications ship with it, so it is likely to also be installed on a high percentage of Windows XP machines. StatOwl indicates that about 80% of NET Framework installations are version 3 or above.
If you're shipping on CD it is no big deal to include the latest .NET Framework on the CD and have it install automatically. If users are downloading your application, it can contact Microsoft's web server to download and install the latest .NET Framework. Online ClickOnce deployment also has this capability if you want people to be able to start their application directly from the web browser without installing it.
So the bottom line is, you probably don't need to worry about whether people will have WPF installed on their machines or not unless your target market consists primarily of dial up customers on Windows XP who don't run much third-party software (i.e., they just run Windows and your application).
Speed
Not an issue. I have a 200 MHz Pentium Pro with 384 MB RAM from 1998 that I test my software on, and my WPF applications have comparable performance with equivalent MFC applications. If your WPF application uses lots of fancy graphics and animation it will run slowly on ancient CPUs and graphics cards, but so would an ordinary MFC application with the same features.
Don't even bother trying to use WPF if you are sticking with Visual Studio 2008 for the next year or two. The experience will be way too painful. I'm talking about "my IDE crashed again" type of pain.
If you are going to use VS 2010 in the near future, then WPF is a blast. Download the beta, a couple of themes off CodePlex, are start playing. Once you get past the (freaking huge) learning curve I think you will find it to be quite enjoyable.
IMHO, you should wait for Visual Studio 2010 and WPF 4.0 to make the actual migration. They will close some very annoying gaps in the product.
Meanwhile, you can try it out. In terms of coding/readability -- it's going to be WAAAY better than with MFC =)
As for the performance and platform -- it shouldn't be a problem unless you have any very special circumstances (like if you can't require users to install .NET).
Also see this related question on switching to WPF from Windows Forms.
If you are thinking about a larger, modular, appliation I recommend checking out Prism. It's a bit of a beast itself, but you should be able to tackle it after coming to grips with C#, Dependency Properties and XAML. Plus, learning Prism gave me a much better understanding of WPF/Silverlight, at least from the development/binding side.
Mike Taulty posted an excellent 10 part video series on Prism. It's a great way to get your head around the platform.
I'd also recommend the pages linked to from the Getting Started page on codeplex. After all that, you're probably ready to tackle the Reference Implementation which comes with the download.
A previous answer of mine might also help clear up any remaining confusion around Controllers/Presenters in the framework that you might have (I did).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
We're starting a new project and are trying to decide to use either Windows Forms or WPF.
I've read some of the other Stack Overflow posts, and realize that WPF has some advantages in the data-binding and appearance areas, but also has a steep learning curve and fairly immature tools and controls.
We would like to better understand if Microsoft is planning on stopping new development of the Windows Forms technology and forcing all new development to eventually go to WPF, or if both technologies will be maintained and improved. (Or are they just going to wait and see how it goes before making up their mind?)
Currently, it seems like WPF is not necessarily the best way to go for line of business applications that don't need extra bells and whistles in the UI. However, it would be good to know if WPF is something we'll need to embrace sooner or later.
This is partially a reasoned argument, and partially a heart-felt rant....
WinForms is based on the user32/GDI technology that has existed since the dawn of modern Windows. It is not going to go anywhere, in all senses of the phrase: it won't get new features; it won't get support dropped.
Or maybe it yet will. The charting API in .NET 4.0 is new and written for GDI, not WPF.
In general, Microsoft has a history with new technologies that looks like the following:
Invent new API.
Innovate with that API for 2 or 3 product cycles.
Realize that continuing to innovate means making unreasonable concessions to backwards compatibility or having realizations that the technology didn't originally address.
Invent new API by wrapping or leaving the existing API around. The existing API doesn't disappear, but new stuff doesn't use it, either.
RDO -> DAO -> ADO -> ADO.NET -> LINQ to SQL -> Entity Framework, toss in some ODBC ... there is a treasure trove of "dead" and wrapped technologies that are still usable and still exist today. These are data access technologies, but the same idea applies; UI frameworks last a little longer because they are the most visible areas of applications.
If I put my Nostradomus hat on, I can safely say that when .NET, oh, 6.0 is out in 2015--which sounds far away but is as close as we are to 2003--WPF will be as "dead" as Windows Forms because some other nifty managed interface will have been created that smoothes over all of the as-yet-undiscovered mistakes and inconveniences of WPF. Who cares? Everything we are yabbering about today will be deprecated by then. (Something is going to have to give in .NET 5.0 anyway because the framework is getting comically large.)
If anything, the thing that Windows Forms has going for it is that it's based on the technology that has existed for well over a decade, and that inertia is not dying anytime soon: the browser you are typing in is using GDI, the taskbar is using GDI, your instant messaging application is using GDI, the new Ribbon control in Windows 7 is using GDI, the $60 printer sitting your desk is using a GDI printer driver, the Windows CE applications running on your phone run a port of Windows Forms and GDI, the new Event Viewer in Windows Vista is using Windows Forms, and there is a large third-party component community behind the Windows Forms platform--WPF is a very small, niche product that only exists in the managed world, which is itself smaller than its unmanaged counterpart.
To this end, I feel that all of these "WinForms vs. WPF" discussions are blowing things out of proportion; the technologies are not mutually exclusive or inferior/superior, as much as Microsoft marketing might have us believe, and Microsoft's developers are smart enough to realize this. They are simply different and one of them happens to be older. If we didn't consider this periodically, we would have all listened to Gartner in 2005 and stopped building Windows applications entirely and moved everything to AJAX on the Web ... with our SOA interfaces ... that expose an alternative REST interface ... that use a TDD DDD model on that backend ... abstracted from the database by an ORM.
Being so eager to abandon a technology for fear of its deprecation only assures our clients that we will maintain a constant level of inexperience and incompetence at programming software solutions.
WPF is part of the future, to be sure, but it's not THE future. Personally, I'm on the fence to see if WPF "makes it" in the UI technology sense that previous data access technologies haven't, although Visual Studio adopting it in 2010 is a pretty comforting sign that Microsoft is actually serious about it by dogfooding it in a flagship product.
To sum up: if you are building a LOB application, I wouldn't feel guilty about using WinForms. If you need an advanced layout scenario, WPF interop is always available to you, just as one enhances a regular Web site occasionally with a Flash object. But for anything else, you owe it to your client to come up with a Good Reason for transitioning the whole team and shell to WPF; Windows Forms has its problems, but half the battle with any platform is knowing what the problems and limitations are, and most of the world (including Microsoft) is still learning WPF.
WinForms won't be deprecated until Win32 is ... which could be quite sometime!
(Remembering that WinForms is basically an abstraction over Win32)
WPF on the other hand has few direct dependencies on Win32 so could potentially form the basis of a "fresh start" UI layer on a future version of windows. At which point I would imagine Win32 (and thus WinForms) will be completely ditched and only available through virtualization. As I said this could be along way off :)
Microsoft's support policy for the .NET Framework and all classes within it is 5+5: 5 years of mainstream support after a release, and then 5 years of extended support is available, or a fee.
With the .NET 4.0 update, including all the WinForms stuff, being released in 2009, you will get 5 years of mainstream support, to 2014 for any WinForms app built on .NET 4.0.
It's likely whatever comes after .NET 4.0 will include WinForms, too, in which case the clock resets.
This 5+5 policy applies to all business-related infrastructure software: Windows, Windows Server, SQL Server, Visual Studio, .NET, and so on.
The point is, you won't have to worry about lack of support for WinForms.
But, the prior posters are correct - the advancements are going into WPF.
I wouldn't worry too much about long term support. WPF may be getting all the love lately, but there's too much WinForms code out there to abandon support. After all, even MFC is still getting updates with each Visual Studio release.
I think Windows Forms will continue to be maintained by Microsoft, but improved upon only in small ways. All of the hot new innovations will go to WPF. Windows Forms is in a similar position as LINQ to SQL. LINQ to SQL is a tight, compact, fast ORM that is awesome, but Microsoft is throwing its weight behind the Entity Framework.
Windows Forms is great for what it is, and what it is used for, which is small, tightly-wrapped applications. It still has many years of life left in it.
If you want an application that will (more) easily port between a web interface, a WPF interface, or a Silverlight (or even a Flex) interface, Windows Forms is probably not for you. These other interfaces use standards-based markup, and an architecture that lends itself better to enterprise development.
I certainly wouldn't call WinForms dead... but I also wouldn't write a new project in it. I would write all new projects using WPF for a myriad of reasons. The biggest is that if you use WPF/XAML, your porting efforts to Silverlight will be much easier.
I went to a WPF preview camp in Redmond a couple of years ago, and I asked this same question to one of the folks working on Crossbow (WPF/Windows Forms interop). His response was that Windows Forms will be supported for the foreseeable future, but could make no guarantees.
Given that, I think you'll be OK basing your application on Windows Forms knowing that you'll have some level of support for the next version or two of .NET (for example, 3-5 years).
I would personally bet closer to 10 years considering Microsoft's continued support for Win32. You may not get boatloads of new features with each release, but you won't be dropped, either.
In any case, I would actually be more concerned with Microsoft's shift from rich-client technologies to web-based technologies, but not enough to ignore opportunities to create compelling applications in either case.
I need to develop a part of a business application in a flashy eye candy way. Therefore wanted to see if I can use DirectX. Here's what I got.
First I read how using C/C++ is like shooting yourself on the foot and I should use DirectX.NET instead. I couldn't disagree. It's the 21st century.
Downloaded DirectX SDK but couldn't find the .NET assemblies in there. Searching the net now revealed that DirectX .NET (called MDX) is now obsolete (released in 2006). And that I should use XNA instead which was mainly developed for XBOX.
Downloaded XNA. But it won’t install because I don't have C#.NET Express 2005 SP1. Installed SP1 on my VS Pro 2005. But it won’t install still. It needs Express 2005 and exactly that single one version, not Pro, clearly not 2008.
Frustrated tried to download C#.NET Express which is free. But the link from MS which says C#.2005 actually downloads C#.2008, because C#.2005 is now obsolete.
And now I read that MS is now putting it's force behind WPF/silverlight. And XNA doesn't support DX10 and Vista doesn't come with DX9.
Now I have two choices:
Go 15 years back and code in plain old C/C++. At least C has proven itself to be timeless.
Try silverlight.
What would be your advice? Or am I missing something?
Udpate: Would like to add that DX10 is not backward compatible with any other DX version. SlimeDX looks really promissing. But as a very new package, I am not sure how much helpful the documentation and tutorials will be.
Udpate 2: It seems that the first download link that google brings up when searching for XNA download, which I used, is not the latest one. Thanks DouglasH for providing the link to v.3. Downloaing it. Probably it will work.
But then agian. Should I switch to WPF/Silverlight? Or go with XNA? Which one is better documented and future-profe?
More update: Vista realy doesn't come with DirectX 9 preinstalled [check by googling]. At least it didn't on my machine bnough last year. Googling for it revealed that I have to manually install DirectX 9 on Vista after downloading it from MS. But my attemet failed beucase hardware drivers for DX9/vista were missing or didn't work. I got the idea that it's not supported that well.
MS has stopped supporting the .net DirectX libraries. There is an open source alternative called SlimDX, and it works well. The documentation leaves some to be desired, but it can be puzzled together by using the DirectX C++ documentation and some common sense.
WPF does pretty good 3D stuff, and there are lot of fish eye panels and source code available for WPF, yes since MS has gone ways from their technology, in today's terms, we can not focus on only one technology by MS to make entire one business application.
Sure we are also tired of using multiple different versions of technologies even to do smallest parts, but I believe they are doing great job by serving billion machines, it sure isnt easy but WPF and .NET seem to be most stable technologies by microsoft and also they are spending good money on making completely managed operating system as well.
If you ever go back to C or C++, you might want to check out Simple DirectMedia Layer (SDL).
IMHO, it is much easier than DirectX.
URL: http://www.libsdl.org/
DirectX is fully backwards-compatible. Any DX9 application will run on Vista and DX10. As for XNA and VS2005 - that's a bit weird. That would make XNA effectively useless. Check if you haven't missed something.
couple of points, which version of XNA did you download. Here is the link for XNA Studio 3.0 which will run on Visual Studio 2008. http://www.microsoft.com/downloads/details.aspx?FamilyId=7D70D6ED-1EDD-4852-9883-9A33C0AD8FEE&displaylang=en
2nd, I sure hope that Vista has Direct X 9, since that is the version of direct X that the DWM runs on in Vista. I think you will find the DLLs for Direct X 9 and before and the DLL,s for DirectX 10 loaded in Vista. Or for that Matter Windows 7 which will also have directX 11 (edit 2 note that the DWM is built on DirectX10, with a software emulator for systems that don't have 3d video hardware, a dx10ondx9 drivers for those with directx 9 cards and of course full support for directx 10 cards).
edit,
Additionally if you downloaded the March directx sdk, you download, directx 9.0c, directx 10, 10.1 and the beta of directX 11. and I would have to check if DirectX 8.x is still included or not although DirectX 9 is backwards compatible with most of that platform.
Though I never worked directly with DirectX (little bit with OpenGL) - I would take WPF. The least-painful to implement (transparency, gradients, brushes, animations, etc.) and it provides solid-performance from what I have seen and experienced myself.
But yes, it's not platform-independent.