我认识的Microsoft新工具：Visual Studio 2005

[MFCPlus]

很久没上CSDN论坛，发现我的一个帖子达到513个回复点，感到很感慨，几个月来的忙碌，真想停下来，到论坛上找些感觉……
一个月前，Microsoft的一位朋友提供了Visual Studio 2005的6月份技术预览版，大约4个G的尺寸，我在三台机器上安装了这个工具包，一台是Windows 2000 Server SP4，一台是Windows XP SP2，另一台是Windows 2003 Server SP1。我感到，VS 2005很庞大，就像Microsoft公司一样庞大，这个东西，已经成了开发人员的Office。有时候我在想，如果Eclipse不是开源的，那么世界上可能真的没有东西可以与Visual Studio相比了，提起Eclipse，我没有Java程序员的那份兴奋感觉，只要你真的了解Visual Studio IDE的构造，也许你也不会对Eclipse感到那样兴奋。
C++/CLI会不会成功，其实是个没有悬念的问题，在正式登场之前一年，C++/CLI就已经是技术网站是的热门话题了，这就是Microsoft，一个面向世界的测试方案就这样完成了，等到今年11月7日正式发行的时候，开发人员已经默认了C++/CLI的存在。ATL、MFC、C++/CLI，尽管许多大师说这些东西很丑陋，可是Microsoft具有“化丑陋为流行的能力”，Microsoft的世界就是这样建造的，不服不行！……

[MFCPlus]

COM能消失吗？
沸沸扬扬的.NET就要升级到2.0版了，那么在VS2005中是否削弱了COM？事实上，对于高手们热衷的C++技术而言，丝毫看不出Microsoft削弱COM技术的迹象，Microsoft不是要淘汰COM，而是希望给COM技术保留一个过渡期，使得COM自然过渡到.NET，然而作为.NET的底层基础，只要.NET存在，COM一定存在，形式上看，.NET的核心需要COM技术作为引导、支持，Microsoft在MFC类库中实现的对.NET控件的支持，无可争辩的表明，.NET控件只不过是ActiveX控件的一个变种，正如每个MFC对象都是从CObject对象派生的一样，每个.NET对象都有一公共的基类，这个类就是Object，从类库的结构上看，.NET类库中一定程度上与MFC类库的结构很相似，或者说将近十年的MFC类库设计经验在.NET类库中正得以体现，每个Object对象可以与一个COM对象形成一个一一对应关系，这一点形成了.NET对象与COM对象互操作的基础。.NET，一个更好的COM，在VC 2005中会得到更好的体现。
Visual Studio Tools for Office，是Microsoft用来替换VBA的面向Office的二次开发框架，借助于一个ActiveX控件，Microsoft实现了Office文档上直接嵌入.NET控件，从这个意义上看，至少目前，.NET的核心深处的东西还是COM技术，因此，即使VS 2005的后续接任者面世，COM依然不会消失，MFC、ATL也不会消失……

[老夏Max]

没有用过.net，不过我的看法更为实际一点：不管什么技术的出现到成为主流，都需要一段很长的“认同时间”。微软的种种技术的出现都是一种积累、尝试的表现，这种积累或者是尝试也许不会得到认同，个人觉得.net刚出现的时候身边一片反对的声音。

[MFCPlus]

关于中文支持：
VS 2005是基于UNICODE的产品，这一点不仅表现在生产的程序上，而且还表现在编译器中，现在，在Visual C++中，你可以如下声明变量：
CString 窗口标题;
你可以如下赋值：
窗口标题 = _T("生产管理系统");
你甚至可以用中文定义一个C++类，例如：

#pragma once


// 测试类 frame

class 测试类 : public CFrameWnd
{
DECLARE_DYNCREATE(测试类)
protected:
测试类(); // protected constructor used by dynamic creation
virtual ~测试类();

protected:
DECLARE_MESSAGE_MAP()
};
不知道这一点算不算一个有意思的变化……

[zhucde]

鉴于VS2005太大,而且C盘至少需要700多M,
直到前天,才下决心安装.

[jiajie828]

UP

[社会栋梁]

比2003人性化,bug也少了

[mintwlf]

2005确实不错，微软似乎不太那么狂妄，又仔细地做了点事情。
To sunhui(MFC.NET)：看了你的这段话之后很有感触，以前和朋友也一起谈过，想谈点我的看法.
其实Visual Studio++6.0已经基本覆盖微软至VS 2005以前的所有开发工具思想，然而VS6.0在98年就发布了，从这个方面就可以看出微软的技术实力了，我们看到的发布的已经是过时的了。微软不是不知道怎样打造好工具，只是出于商业竞争的需要不想过早地公开一些新技术。

[gohappy_1999]

mark

[liucaizhi]

牛.

[MFCPlus]

Microsoft的可视化技术为什么偏袒基于Windows Form程序？
Visual C++面世十多年了，在这个框架中，“Visual”体现在哪里呢？自从Visual Studio 2003 .NET开始，Microsoft才允许基于托管框架的Form、UserControl等对象在C++意义上进行所谓的可视化设计，在此之前的10年时间里不客气地说，“Visual”对于Visual C++而言，仅仅是个修饰词而以。著名的MFC框架至今也不能做到可视化，难道Microsoft没有这个能力？我研究过Microsoft的Visual Basic for Application SDK，本来这是一个相对容易的框架，Microsoft提供的一套开发办法将这个SDK反而搞复杂了（其实，Microsoft完全可以使得问题变得简单），因此扶植了一个第三方公司对此进行技术支持，也许，将问题变得复杂，对应的东西也就增值了。基于Form的框架，对于大多数开发人员而言，十分易于上手，而对于那些偏执于C++的程序员而言，却不是一个好的事情，因为基于C++编码不是很容易实现基于Form编程所实现的效果，这一点是C++程序员的内心苦涩，在一定程度上也隔开了C++程序员与非C++程序员，也许是因为缺乏强劲的竞争对手，使得Microsoft如愿的将开发人员纳入了他所规定的开发模式，我们注意到，大败Netscape之后，IE几乎不升级了，因此人们针对Microsoft的垄断有了切肤之痛的感受，我们回头看看C++，Microsoft的VC++，1998年经典的VC++6出来后，作为VC骨干成分的MFC、ATL基本上就是形式上的改变，直到今天，除了IDE越变越华丽之外，MFC/ATL几乎没有变化，显然Microsoft用于开发Office、Visual Studio .NET IDE的GUI是个内部的公共软件库，而且这些东西不是“托管”的，托管代码仅仅是通过“挂接”途径介入Office、Visual Studio .NET IDE之中的。也就是说，Microsoft自己很少用其商品化开发工具中提供的东西，即使用，他们的使用方法也不同于我们，VC 6.0框架、IDE完全是用MFC/ATL开发的，Microsoft能做到，我们却无法做到，因为不经意间，我们可能被引入了一个预先设计好的路途，使得我们的创造力仅仅就是能够开发个什么工程、实现个什么小玩意而已。
VC 2005中，C++/CLI是可视化的，前提是你必须设计Form框架下的软件，借助于一个动态链接库，Microsoft允许你在MFC中使用UserControl控件，除了这些特别的之外，VC++中可能没有什么新的景色，对于GUI发烧友而言，华丽的VS IDE会催生新一轮的Microsoft的模仿秀，这一点正是Microsoft愿意看到的，如果你想做一些有意义的东西，突破Microsoft预设的思维屏障，是你的（开发者的）的问题。WinForm的可视化设计，使得大多数软件开发者变得“惰性”，使得传统的C++程序员离大众越来越远，因此对Microsoft的冲击力也就越来越弱了。从这一点上说，Microsoft的策略是对的。

[xxrl]

感觉vc6长时间内都不会被替代

[WuOu]

汗...-_-!

[darkstar21cn]

偶用了一段时间的beta　1，没拿到beta　2所以，不敢枉下结论。

至少对C++标准的支持，偶已经没什么可说的了－－偶用的它都能支持了。

[DentistryDoctor]

没用过，不敢发表评论。

[linur]

前几天写了一个模板类，发现VC2003不支持export关键字，MSDN上也说了不支持，而标准C++已经出现5、6年了，很郁闷的事情，不知道VC2005有没有加入这个关键字

[MFCPlus]

to linur(林夕):
VC++ 2005 支持STL，因此当然支持关键字export!

[iceqings]

欢迎加入Visual C++ 开发 QQ群

群号：9643456

有不能解决的问题吗，加入我们，让我们共同解决

[MFCPlus]

更加严格的语法
Visual C++2005的语法比以前的版本更严格，在之前的所有版本中，如下代码均正常编译：
for(int i = 0; i< 10; i++)
{
}

i = i +5;
在新版本中，会产生编译错误，原因是变量i未定义，这一点，将导致大量的第三方类库必须修改，虽然是不大的问题，但却受习惯制约。

Managed C++向C++/CLI迁移
Managed Extension，是Microsoft在2000能就开始向大众推崇的东西，2005年Microsoft的思维有所变化，这一点会不会带来混乱，或者说是不是一个玩笑，只有时间才能判断，可以说，VS 2002时期，Managed Extension只是个铺垫，Visual Studio 2003推出后，Managed C++才找到了位置，然而2005年一切又都变了，Managed C++向C++/CLI转移肯定会带来习惯的问题。对C++程序员而言，“引用”、“委托”等概念还是很陌生的，即使是1997年面世的ATL，虽然8年过去了，大多数程序员提起ATL，也许还是“敬而远之”，我接触过许多MFC程序员，都有8-10年的开发经验，但提起ATL还是畏之如虎的感觉，Managed C++也快5岁了，但熟练驾驭者真是寥寥无几，C++/CLI来了，情况会怎样？这场Microsoft导演的混乱会怎样收场，我们拭目以待。

ATL/MFC，高手的左膀右臂
从VS 2002开始，Microsoft将ATL、MFC放到同一个目录中，VS2005亦如此。大概VC6开始，Microsoft允许MFC与ATL混合使用，早在1998年以前，由于Microsoft的一个VC开发组的技术人员在互联网上的一篇文章，使得经过手工调整后，MFC与ATL可以在一个工程中同时使用，VC6改变了这一切，到了VS 2005，我们看到ATL与MFC耦合得更紧，然而对程序员来讲，ATL对MFC编程究竟有什么好处，还是一个未知的变数，原因之一是，Microsoft没有提供相关的范例，可以说，几年来，Microsoft的例子如同MFC/ATL一样，虽然VS的尺寸越变越大，可是例子还是那么几个。国内能够综合运用MFC/ATL开发的人选有多少，是个无法统计的问题，但感觉表明，不会太多，这层窗户纸何时被捅破，是个有趣的话题，真切希望ATL、MFC能够成为国内程序员的左右手。

[dawndu]

偶还再用vc6,没有觉得要换工具

[casinosun]

能不能告诉我为什么在button——click中写个SendMessage，都不对，写MessageBox也不对，微软到底怎么了，和vc6差这么多，怎么用呀