views:

89

answers:

4

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.

+2  A: 

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"

James Curran
+1 for suggesting a DSL. However, in my experience, DSLs that are built on top of an existing language, no matter how cleverly disguised, tend to have a lot of their own syntax rules and surprising quirks, which programmers can understand, but not ordinary users.
OregonGhost
Interested approach, although I enjoy learning new languages they would require additional installations onto the superiors machine. Hell, I can't even get them to update some of our internal software.
Stevoni
A: 

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.

rdkleine
+1  A: 

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.

OregonGhost
Another good idea with the dual application approach. I'm not looking to modify the second app, I'm looking to create a second app.
Stevoni
A: 

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:

  • Define the syntax.
  • parse & token the source code.
  • create meaning instructions from the parse tree. (i.e. "compiling it")
  • generate IL code from those instructions.

This is a significant amount of work, although there are some tools to help:

  • Irony does much of the work for parsing and some of the compiling and code generation.
James Curran