高难度的问题，微软居然没有开放这个功能

[superzxf]

自己实现了一个窗体设计器，现在可以进入设计模式，拖动控件并设置属性，这些都没问题了
现在的关键问题是需要实现一个CodeDomDesignerLoader，这个类主要实现两个功能，通过CSharpCodeProvider把设计器的CodeCompileUnit对象生成C#代码，和加载C#代码还原为CodeCompileUnit对象
第一个功能没有问题，CSharpCodeProvider提供了GenerateCodeFromCompileUnit方法，可以生成标准的C#代码
第二个功能就郁闷了，CSharpCodeProvider居然没有实现Parse方法！一看说明文档才知道微软并没有实现这个方法，需要用户自己去实现，而微软肯定是实现了这个方法的，不然他自己的VS怎么识别？只是没有放在.netframework中，微软也真是的，把事情干一半，然后说另一半你来搞定，操
我用的是.netframework2.0，哪位用过3.0或3.5的，看看这个方法实现了没有？
要是真的自己实现这个方法，会出人命的，复杂的字符串分析，整个一个语法分析器啊，网上找了一些代码研究，都是上万行的代码量，晕死
或者有没有其他的方法可以绕过语法分析，可以把运行时的对象转换成CodeCompileUnit

[superzxf]

[Quote=引用 25 楼 gbb21 的回复:]
微软内部解析器是有的，而且还是个专门的产品，不过只供内部使用，哈哈；）
不过lZ的问题貌似的确不用解析器啊，又不用解析所有表达式，对吧？
[/Quote]

不会还要花钱吧？
把代码还原为CodeDom其实就是解析的过程，要把所有的语法元素分解成CodeDom对象

[superzxf]

[Quote=引用 27 楼 yanrabbit163 的回复:]
引用 11 楼 hongqi162 的回复:
C# code
dotnetframework3.5sp1

CSharpCodeProvider cSharpCodeProvider = new CSharpCodeProvider();
TextReader textReader=null;
//---
cSharpCodeProvider.Parse(textReader);


没有问题
[/Quote]

真的测试过没问题吗？如果真的可以就好了，实在不行就升级到3.5了

[ProjectDD]

楼主的核心问题,是把C#代码重新映射到窗口设计上,

你需要一个功能强大的TextBox控件,然后去分析,建立关键字表,使用DOM

好象很复杂

[W422080367]

[Quote=引用 15 楼 lovefootball 的回复:]
你试试先调用CreateParser得到一个ICodeParser
然后用这个ICodeParser 的Parse方法

[/Quote]
、

[edwardsoft]

高！实在是高！

[fengyecsdn]

当然 没有，，，，，，， C#的代码模型本身就没作完，，

[dangdang2471]

有理想。
顶楼主

[CsToD]

貌似SharpDevelop实现了这个，这个软件是开源的，你可以下载源文件，或者.DLL文件

[CsToD]

楼主太天真了，11楼明显是忽悠人的，27楼还在那里起哄。

楼主，你看清楚：

dotnetframework3.5sp1

CSharpCodeProvider cSharpCodeProvider = new CSharpCodeProvider();
TextReader textReader=null; //这是一个null，怎么能用？
//---
cSharpCodeProvider.Parse(textReader);

根本没实例化，汗。。。

[superzxf]

[Quote=引用 39 楼 CsToD 的回复:]
楼主太天真了，11楼明显是忽悠人的，27楼还在那里起哄。

楼主，你看清楚：

dotnetframework3.5sp1

CSharpCodeProvider cSharpCodeProvider = new CSharpCodeProvider();
TextReader textReader=null;//这是一个null，怎么能用？
//---
cSharpCodeProvider.Parse(textReader);

根本没实例化，汗。。。
[/Quote]

我不会照搬人家的代码的，只要了解其思路即可，至于这个代码是否真的可以运行并不是主要的问题
所以并不关心textReader是否为null，而只关心cSharpCodeProvider.Parse是否实现，最终的代码肯定会根据自己的习惯重写

[lextm]

首先，对于DOM方面，现在框架的支持确实不太好。至于现有的C#代码解析，开源的Mono框架的编译器和SharpDevelop的编辑器都是可作为参考的。

其次，其实lz的应用只是希望运行时执行新的C#代码来改善程序。这样就要求C#脚本化，可以随写随编译。

Mono框架由于编译器就是用C#写的，所以可以将编译器的相关方法以开发API的方式暴露出来，因此已经实现了C# Shell效果，可以将C#作为脚本来使用。假如将这个Shell嵌入到应用程序中，就可以实现lz的需求了。你可以参考Mono相关的资料尝试。

至于微软的C#编译器，一直以来都是C++等技术做的，所以暂时还不能提供类似的接口。从PDC 2008的Anders演示来看，大约要到VS2012的时候才能实现类似的特性。届时CodeDOM接口就可以不用了

[superzxf]

楼上的强人，了解的真多啊
mono大概看了一下，太庞大了，要把其中的编译器扣出来不是一时半会能搞定的
原来微软的编译器是用c++做的，怪不得没有.net的实现，vs2012妈呀太恐怖了，要是微软到时有搞个啥新玩意代替CodeDom，那不是白折腾了？
看来还是不折腾好，呵呵

[lextm]

其实你为什么不把Mono那个编译器exe改成dll结尾，然后直接添加引用试试看呢？说不定里面直接有你要的API。对于开源的东西，有时候文档总是不够多，代码又太多，不如做做实验好了。

[Formular1]

这部分微软不是用.net做的。

[hangang7403]

UP

[捷哥1999]

新年第一天看到这个帖子，长进了，这里都是高手呀。

[chengxiaorong]

顶下把

[king520520]

微软实现了!

[superzxf]

[Quote=引用 47 楼 king520520 的回复:]
微软实现了!
[/Quote]

能详细说下吗？

[WQ771211]

采用界面和逻辑分开的方法，用xml存界面，cs存代码
代码和"界面设计器"无关，就不存在这个问题了
要即时编译的时候，把xml转换为cs就行了（这个微软是提供了的）