使用CodeDom生成代码 [英] code generating using CodeDom

问题描述

大家好

我使用CodeDom生成了一个表单代码，并且我成功编译了它，但是我的问题是我得到了基于控制台的表单应用程序！''
如何消除控制台背景?

预先感谢

hi everybody

i generate a form codes using CodeDom, and i compile it successfully but my problem is i get console based form app''!!!

how can i eliminate that console background??

thanks in advance

推荐答案

好，因为OP对使用动态编译的程序集的替代方式表示了兴趣，所以我开始草绘设计.

简介:我曾经开发过一些用于动态或在运行时添加程序集的设计.一种选择是从可执行文件添加程序集.这样的程序集可以在运行时加载一次，直到主机应用程序运行时结束为止，这很容易(我称之为插件体系结构)，也可以定期卸载或加载，这比较困难，因为存在没有方法可以卸载已加载的程序集-从概念上讲，是.NET设计的，因此应使用System.AppDomain(我们称其为动态模块化设计).另一个机会是将代码DOM的程序集生成到主机的内存中.我们称其为IDE设计.我使用IDE设计来创建常规的C#(或任何其他基于.NET语言的计算器)以及符号计算器，这是我的计算机代数系统(CAS)计算器的一部分.由于计算器设计没有在CAS上公开我的专业知识，因此我可以分享.自然，IDE设计仅应与应用程序域一起使用，因为IDE应该允许无限数量的重新编译.本质上，主机应用程序为主机提供了用于以与主机相同的过程来构建和运行小型应用程序(简称为Applet)的主机，但是在不同的应用程序域和线程中.
与插件或Applet和System.AppDomain 的接口:看一下我最近对另一个问题的回答:
Applet托管界面:让我们回到IDE设计. Applet托管接口应该执行以下操作:它应该能够以一个或多个字符串的形式获取将来的Applet的一些源代码，每个字符串代表输入文件.代码DOM具有编译此类源代码的选项.要使用的另一个选项是将其编译到内存中.编译结果(错误，代码行号等)应通过应用程序域"边界传递给主机. Applet托管界面的另一种方法是运行"已编译Applet的某种方法，并以主机可访问的某种方式重定向输出.让我们考虑这样的输出.

Applet输出:应该设计这种方式，但是主要原理是通过IPC进行工作，因为数据应该通过Application Domain边界(从Applet的Application Domain传递到宿主Application Domain)传递，并且还分派到主机的UI线程.在我的项目中，输出只是一个字符串(在一个表示将HTML传递给Web浏览器控件的项目中).对于这种简单的数据传输，可以使用简化的方法System.AppDomain.对于更复杂和耗时的数据传输过程，应使用基于传输IPC的阻塞队列:WCF或基于Windows命名管道的远程处理.将事件分配到UI线程应该完全在主机应用程序域"端完成，请参见: Treeview扫描仪和MD5的问题 [ ^ ].

Applet界面:Applet托管界面应如何识别要运行的Applet方法.应将其定义为特殊的Applet接口，并在编译后由主机实例化(在Applet应用程序域方面).使用与插件或Applet和System.AppDomain的接口"部分中所述的相同原理来完成此操作.

一般操作顺序:这是主机应用程序的主要周期.用户键入applet的代码(可以通过自动添加一些常见的结构来简化它)或从外部文件中加载代码.主持人应具有单身人士( http://en.wikipedia.org/wiki/Singleton_pattern [System.AppDomain的对象的http://en.wikipedia.org/wiki/Singleton_pattern"target =" _ blank"title =" New Window> ^ ])对象被延迟初始化(http://en.wikipedia.org/wiki/Lazy_evaluation [ ^ ]).如果先前创建的实例存在，则应将其卸载.这是使用应用程序域的全部要点，否则无法卸载任何程序集将造成严重的内存泄漏.将创建新的应用程序域，并通过应用程序域边界将源代码和选项(尤其是计算机语言的ID！)传递给Applet主机实例. AppDomain.GetData/SetData可以很好地用于这些目的.代码被编译到Applet应用程序域中的内存中，错误被传递回主机.可以按照与Visual Studio中相同的方式将错误呈现给主机的UI.如果构建成功，则新的程序集将出现在Applet应用程序域的内存空间中. Applet主机接口尝试使用Applet接口根据上述架构识别入口点对象.如果此过程失败，则状态将被传递回主机的应用程序域并显示在UI中.如果获得了对Applet主机的引用(实例化实现Applet接口的入口类)，则Applet入口点将运行，输出将传递到主机. Applet的编译和运行应从一开始就在Applet的Application主机中创建的单独线程中完成.主机需要一种通过应用程序域边界中止此线程的方法.很好，Applet的应用程序域中的所有资源的回收不完全的问题并不重要，因为此域将被周期性地卸载. Applet接口代码运行周期结束后，该事件通过应用程序域边界传递到主机.主机UI使用户可以启动新的编译/运行周期.

-SA

OK, as OP expressed interest in my alternative way of working with dynamically compiled assemblies, I''m starting to sketch the design.

Introduction: I used to develop some designs for adding assemblies dynamically or during run-time. One option is to add assemblies from executable files. Such assemblies could be loaded during run-time once and until the end of the run-time of the host application, which is easy (I call it plug-in architecture) or periodically unloaded or loaded, which is more difficult, because there is no way to unload a loaded assembly — conceptually, by .NET design, so System.AppDomain should be used (let''s call it dynamic modular design). Another opportunity is to generate assembly from code DOM into host''s memory. Let''s call it IDE design. I used IDE design to create a conventional C# (or any other .NET language-based calculator) and also a symbolic calculator, a part of my Computer Algebra System (CAS) calculator. As the calculator design does not disclose my know-how on the CAS, I can share it. Naturally, the IDE design should only work with Application Domains, because the IDE should allow for unlimited number of re-compilation. In essence, the host application provides the host for building and running small applications (let''s call them Applets) in the same process as the host, but in different Application Domain and thread(s).

Interfaces with plug-ins or Applets and System.AppDomain: Take a look at my recent Answer to a different Question: Create WPF Application that uses Reloadable Plugins...[^]. Please understand that some more advanced aspect of this discussion are highly controversial and needs some development. Here we only need to discuss the IDE design which is much more certain and well-defined compared to the very indeterminate requirements of Ven''s project which is probably in an early inception phase. Important point in this reference for IDE design is: how to define interface with the plug-in (in our case it will be the Applet, so mentally replace "plug-in interface" with "Applet interface"), how to recognize and instantiate the entry class in the Applet by the host''s code and how to work across the boundary beteen different Application Domains. Let''s assume it is more or less clear.

Applet hosting interface: Lets go back to IDE design. The Applet hosting interface should do something like that: it should be able to get some source code of the future Applet in the form of one or more strings each representing the input file. Code DOM has the options to compile such set of source codes. Another option to be used is to compile it into memory. The result of compilation should (errors, code line numbers, etc.) should be delivered to the host through the Application Domain boundary. Another method of the Applet hosting interface would be to "run" some method of the complied applet and re-direct output in some way accessible by the host. Let''s consider such output.

Applet output: This way should be designed, but the main principle is working via IPC, because the data should be passed via Application Domain boundary (from Applet''s Application Domain to host Application Domain), and also dispatched to the host''s UI thread. In my projects, the output was simply a string (in one project representing HTML passed to Web browser control). For such simple data transfer a simplified method of System.AppDomain can be used. For more complex and time consuming data transfer process a blocking queue based on transport IPC should be used: WCF or remoting, based on Windows named pipes. The dispatching of events to the UI thread should be done entirely on the host Application Domain side, see: Control.Invoke() vs. Control.BeginInvoke()[^], Problem with Treeview Scanner And MD5[^].

Applet interface: How Applet hosting interface should identify what Applet method to run. It should be defined as a special Applet interface and, after compilation, instantiated by the host (on Applet Application Domain side). It is done using the same principles described in the section "Interfaces with plug-ins or Applets and System.AppDomain".

General order of operation: This is the main cycle of the host application. The user types the code of applet (it can be simplified by adding some common constructs automatically) or load the code from external file(s). The host should have a singleton (http://en.wikipedia.org/wiki/Singleton_pattern[^]) object of the type System.AppDomain initialized lazily (http://en.wikipedia.org/wiki/Lazy_evaluation[^]). If previously created instance exists, it should be unloaded. This is a whole point of using Application Domains, otherwise inability to unload any assemblies would created a strong memory leak. New Application Domain is created, source code and options (in particular, ID of computer language!) delivered to the instance of the Applet host through the Application Domain boundary. AppDomain.GetData/SetData would work fine for these purposes. Code is compiled into memory in the Applet''s Application Domain, errors delivered back to the host. The errors can be presented to the host''s UI in the same way as in Visual Studio. If the build is successful, the new Assembly appears in the memory space of the Applet''s Application domain. Applet host interface try to identify entry point object according the the schema described above, using Applet interface. If this procedure is failed, the status is delivered back to the host''s Application Domain and presented in the UI. If the reference to the Applet host is obtained (entry class implementing Applet interface instantiated), Applet entry point is run, output is delivered to the host. The compilation and run of Applet should be done in the separate thread created in the Applet''s Application host from the very beginning. The host need a way abort this thread through the Application Domain boundary. What is good, any problems of incomplete reclaiming of any resources in the Applet''s Application Domain and not critical, because this domain will be unloaded in cycle. When Applet interface code run cycle is finished, the event is delivered through the Application Domain boundary to the host. The host UI enables the user to start a new compile/run cycle.

—SA

我相信在类名为"target"(不是平台)的类中有一个选项，应该设置为WinExe. br/>
John建议的方法可能不起作用(肯定不知道)，因为如果将Form Project输出更改为Console应用程序，建议的代码不会隐藏控制台.

I believe there''s an option in a class somewhere called ''target'' (not platform) which should be set to WinExe.

The method suggested by John might not work (dunno for sure), because the suggested code does not hide the console if you change a Form Project output to Console application.

// Define parameters to invoke a compiler
System.CodeDom.Compiler.CompilerParameters _CompilerParameters =
        new System.CodeDom.Compiler.CompilerParameters();

// by entering  '' /target:winexe '' we will all set to go!!
CompilerParameters.CompilerOptions = "/optimize /target:winexe";

感谢''nbgangsta''给了我线索！

如果我们有System.CodeDom.Compiler.CompilerParameters对象，则可以在该对象的CompilerOptions参数中设置目标选项[参见上文].

默认情况下，此选项为"/target:exe"，它将创建" .exe "文件

有关更多信息，请参见此 [

thanks to '' nbgangsta '' for giving me the clue!!

if we have a System.CodeDom.Compiler.CompilerParameters object, we can set target option in this object''s CompilerOptions parameter [ see above ].

this option by default is '' /target:exe '' which create an '' .exe '' file

for further information see this[^]

这篇关于使用CodeDom生成代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！