.NET 应用程序来编写和构建另一个应用程序
在我不断努力兑现承诺和超额交付的过程中，我希望制作一个 .Net 工具来创建非程序员上级可以使用的简单 .Net 应用程序。我将如何编写和编译代码？
意图说明：我希望我的上级不要要求我制作条形码标签应用程序，而是选择几个选项，进行一些测试打印，然后创建应用程序并准备好重复使用。但是我该如何编写输出应用程序以便它们在其他机器上重用呢？
另外，这是一个糟糕的想法还是有一些优点？
编辑：对于所有对我最初的问题提出可配置性建议的人：我们发布的供内部使用的所有应用程序基本上都是由临时工使用的，而我的上级更喜欢这些应用程序是静态的且不可配置的。话虽这么说，我们的一些应用程序已经五六年没有改变了，因为它们是按照所需的规格制作的。在过去的几周里，他们请求了 2 个新的条形码应用程序，并顺便请求了第三个应用程序。
In my constant strive to under promise and over deliver I'm looking to make a .Net tool to create simple .Net applications that the non-programmer superiors can use. How would I go about writing and compiling the code?
Explanation of intent: I want my superiors to, rather than ask me to make a barcode label app, select a few options, do a few test prints and then have the application created and ready to reuse. But how do I go about writing the output application for them to reuse on other machines?
Also, is this a terrible idea or have some merit?
Edit: To all those suggesting configurability over my original question: all the apps we release for internal use are being used by essentially day labor and my superiors prefer the applications to be static and unconfigurable. That being said, some of our apps haven't changed in 5 or 6 years because they were made to the specifications required. In the last few weeks they have requested 2 new barcode apps with a third requested in passing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是可能的，尽管需要做很多工作。
我自己还没有尝试过，但我会告诉您创建此类应用程序的最简单方法（技术上称为“域特定语言”）是从某种动态语言（例如 IronPython 或 Boo）开始并构建您的应用程序语言之上（动态语言让你添加新命令）
我的一个朋友，名叫 Ayende Rahien，甚至写了一本关于这样做的书："Boo 中的 DSL：.NET 中的领域特定语言"
This is possible, although it is a lot of work.
I haven't tried this myself, but I'll told the easiest way to create such a application (technically knows as a "Domain Specific Language"), is to start with some dynamic language (such a IronPython or Boo) and build your language on top of it (Dynamic languages let you add new commands)
I friend of mine, who goes by the name of Ayende Rahien, even wrote a book about doing exactly that: "DSLs in Boo: Domain Specific Languages in .NET"
您基本上是否想要选择应用程序的外观和打印条形码的方式，并从中生成一个正常工作的新应用程序？即，您只想创建不同（定制）类型的条码打印机应用程序？
如果是这样，我建议将所有可选选项视为数据。制作一个生成器应用程序，让您可以轻松选择任何内容，并将其写入数据文件。创建第二个应用程序，它将读取数据文件并让用户创建条形码。第二个应用程序以及数据文件是您生成的应用程序，您可以使用生成器应用程序来部署它。然后，生成器可以允许用户选择输出文件名，并将第二个应用程序连同数据文件复制到该位置。这是一个两个文件的解决方案，但它允许“创建”和部署自定义条形码打印应用程序。
如果它绝对必须是单文件解决方案，请查看资源 API，它可能允许您更新第二个应用程序的资源，以便您可以将数据文件注入可执行文件中。
如果这是关于更多，即您希望用户能够添加您没有想到的功能，那么您可能会更幸运地使用脚本语言，就像 James Curran 所解释的那样。
Do you basically want to select how the app looks and prints barcodes, and from that generate a new app that just works? I.e., you just want to create different (customized) kinds of barcode printer apps?
If so, I'd suggest treating all selectable options as data. Make a generator app that allows you to easily select anything, and write that into a data file. Make a second app that will read in the data file and lets the user create the barcodes. This second app, along with the data file, is your generated application, and you deploy it with the generator app. The generator can then allow users to select an output file name, and copy the second app along with the datafile to that location. This is a two-file solution, yet it allows to "create" and deploy a custom barcode printing app.
If it absolutely must be a single-file solution, have a look at the resource APIs, which may allow you to update the resources of the second app, so you can inject the data file into the executable.
If this is about more, i.e. you want users to be able to add functionality that you did not think of, you may have more luck with scripting languages, like James Curran explains.
您不是说配置应用程序吗？
为用户提供您正在讨论的选项，并让他们将这些选项保存到数据库中，以便其他用户可以利用这些设置。
Don't you mean configuring the application?
Give the user the options you are talking about and let them save these to a database so other users can take advantage of these settings.
好吧，如果您不喜欢我关于动态语言上的 DSL 的第一个想法，那么您必须从头开始创建整个语言。这意味着：
尽管有一些工具可以提供帮助，但这是一项大量的工作：
OK, if you didn't like my first idea of a DSL on a dynamic language, then you've got to create your whole language from scratch. That mean:
This is a significant amount of work, although there are some tools to help: