This project has moved and is read-only. For the latest updates, please go here.

Should we move to VS2008?

Jul 14, 2008 at 8:34 AM
I guess we can't hold off on this forever and I finally have VS2008 installed.
Unless there's any violent objections I might start creating a VS2008 project version of the extension kit and start porting some of the code to use some of the more useful C#3 features eg (object initializers, automatic properties)

Jul 14, 2008 at 1:17 PM
I say go for it. I've been working with vs2008 since it came out and its so much better than vs2005.
The only solution left in vs2005 is the client solution and it needs to be updates soon.
Jul 14, 2008 at 1:38 PM
I have moved to 2008 as well and think that it's a good idea to move this project. There are so many nice 2008 features that it's now hard for me to go back to work with 2005 :-)


Jul 14, 2008 at 2:35 PM
I vote for moving to VS 2008 also. I am using VS 2008 since RTM and I have completely uninstalled VS2005.
Jul 15, 2008 at 6:21 AM
Edited Jul 15, 2008 at 11:04 AM
Done. I love Object Initializers, Automatic Properties and judicious use of Anonymous Types...

I'm usually a sucker for upgrading to the 'latest' but I couldn't see any reason to update the target framework to .Net3/3.5 - since we don't need or use any of the features I can think of.
Jul 17, 2008 at 7:47 AM
You are right. If you do not use 3.5 features, there is not reason to upgrade target framework. 3.5 has some problems for now: Win 2000 incompatibility and very big installation package. 3.5 SP1 should address the second but the first not :-(
Jul 22, 2008 at 12:27 PM
Edited Jul 22, 2008 at 12:32 PM
One minor concession, I will target 3.5 for the Tests project CABDevExpress.ExtensionKit.Tests.
The reason is, I want to play with Extension Methods with XUnit.
I find the "fluent interface-type" syntax quite interesting...

Assert.Equal(0, navbarWorkspace.Groups.Count);   // *OLD* - how it used to be done
navbarWorkspace.Groups.Count.ShouldEqual(0);    // *NEW* - uses the Extension Methods that come with XUnit (in xunitext35.dll)

Jul 27, 2008 at 6:52 AM
Edited Jul 27, 2008 at 6:53 AM
I just read recently, that Extension Methods don't actually need to target .NET3.5
Everything VisualStudio does and is set up to do, will lead you to believe this...
But there is a hack to get around it - see The MOTH ExtensionMethod hack to target .NET2
Jul 27, 2008 at 4:09 PM
Yes, we are using extension methods in FW 2.0 for many months - just in this manner. Without any problem. The only problem I have read about is that this does not work for ASP.NET.
Oct 23, 2008 at 2:50 PM
And what about the rest of us, who bound by corporate rules and are still using studio 2005??
at least you could make the library compatible with 2005

Oct 25, 2008 at 2:53 AM
Edited Oct 25, 2008 at 3:08 AM
Perhaps there's a volunteer to help keep the VisualStudio2005 version of the project up to date?

The library (assembly) still targets .Net2, so you can still include it as a reference in VS2005.
You could probably use Vs2008 Express (if you remove the solution folders from the project) and then compile DevExpress.ExtensionKit to an assembly - from where you can include it in your VS2005 project.

I would hope that a corporation would allow you to action this workaround.

Oct 30, 2008 at 12:35 PM
As long as we can use it from .net2 is fine.
I love vs 2008, but rules are rules here. Till they get vs 2008 here my hands are tighed up.


Nov 11, 2008 at 5:23 PM
Thanks for advice.

i managed to compile the stuff from Vs2008 Express. It works fine. Excellent.

Thanks again
Nov 20, 2008 at 1:30 PM
Edited Nov 20, 2008 at 1:31 PM
If you need volunteers to add patches and maintain the project, I am interested. I have got a number of issues I found and it seems everybody else is to busy to fix them. So I could at least patch the issues I found myself.