For a little night project I would like to write a validation component that could be used in .NET application to do the usual and tedious validation of object, input parameters and post conditions.
My first idea was to dump all this validation setup logic into a XML configuation file and provide a liquid interface for the people that would like to have it in code.
Because I would like to deliver something that is actually usable I thought about providing a specialized DSL (domain specific language). The question is what tools should I use to do this?
I thought about parsing it by hand using regex. But personally I would like to have something more...usable.
So what would you suggest?
It sounds like you're talking about implementing one of .Net 4.0's features, code contracts.
So I guess my recommended tool would be VS.Net 2010.
If you're looking specifically at a DSL, have a look at the ANTLR project. We've used it at my company quite successfully in the past.
The thing with DSl's is that they rarely are effective in isolation. To be useful for writing real software, you really need to be able to embed the DSL inside a host language. Compare, for example, the way Linq works vs just straight SQL. Another good example is XML literal feature in VB. Both let you write real code, in a general purpose PL and inter weave it with simpler declaritive DSL code.
The result is something much more powerful than stand alone SQL or a simple XML editor.
The downside to this, unfortunately, is that neither C# nor VB offers any meta programming features, so the only way to do that for mainstream .net devs is to build your own language. If this is something you are doing just for fun you might be able to modify the mono C# compiler to add the features you are interested on to the language. Another alternative might be to try ruby. It has a flexible syntax whic let's you get away with a lot of crazyness. Personaly, however, I would prefer the hacked C# approach.
Might want to check out Building Domain Specific Languages in Boo (Boo is a CLR language, concepts should carry over to C#). An example project is Simple State Machine.
Take a look at Oslo from Microsoft, not sure if it does what you want, but I know that you can build DSL parsers and specify grammars and have it generate class libraries that can parse data based on the grammar.
More details of the "M" language and how to use it are here
Why go so far? Start off using generics and a fluent interface. Start simple and work it through some production. If the friction is too high dealing with a fluent interface, then look at using a DSL.
You can try DSL Tools for Visual Studio.
You should look at Irony project at http://irony.codeplex.com/
Related
Environment
Windows 8.1 64bit
Microsoft Visual Studio
C#
What I'm trying to do
To implement a mini language in C#
My job in my company is to make a software which automates evaluation of the performance of company products. The evaluation involves opening valves, flowing chemicals, fetching signals from sensors, calculating some values, etc...
The issue is when a user wants to change the procedure and parameters like how long the reaction time is, the order of opening valves, whether reaction conduit is flushed out or not, the programmer has to change the source code and build another software every time the user requires it.
So I'm trying to implement a mini language in C#. A user can organize a procedure of measurement with the easy-to-understand language. The user writes a code in a txt file, my software reads it, parse each line of code, extract commands and parameters, call corresponding method in the software.
For example, a user writes a line of code like open_valve(3), my software reads the code and call an internal method send_commands_to_ADconverter(VALVE, 3) which sends appropriate commands to a target valve via an A/D converter connected to the computer. This is my conception.
However, due to lack of my programming skill, I have no idea where to start. What technology is available? What are the keywords to achieve the goal? How can I achieve this objective? Any help would be appreciated. Thanks.
Edit 1
c# - Adding scripting functionality to .NET applications - Stack Overflow doesn't refer to accessing external devices like sensors, valves via A/D converter which is crucial for my purpose, so it is unclear this is a duplicate question of the link above.
In order to create a language you need a "parser" of some sort. You will need to define a "grammar". Parsing your "progam" via the grammar will result in a structure that you can then call methods in your code that implement each feature of your language.
You are on a big learning curve here :) lots of strange things like EBNF. You will probably see lots of references to things like Gold and ANTLR. These are hugely capable but involve things like "compiler compilers" and add a level of complexity that can be confusing and require extra steps in you build pipeline.
Here are a couple of libraries I've used that allow you to define you grammar in c#.
https://github.com/picoe/Eto.Parse
https://irony.codeplex.com/
Irony is very good (I've used it for various projects) but hasn't been maintained for a while.
Eto.Parse is more recent. It also has built in parsers that allow you to create a Grammer by parsing BNF. This is very cool
If I understand, your goal is to parse a syntax written by your user and take a decision with what he typed.
I suggest you to use regular expression to match and split the user input.
There are several scripting languages which can be run directly from C#.
As your users doesn't seem to have programming knowledge it might help to use a verbose language like VBScript.
To run VBScript you can use the Scripting Control. See this question for samples: Use Microsoft Scripting Control to evaluate 'If' expressions (via c#)
IIRC the script control must be run as a 32bit application.
Well, the easiest option would be to use what you already have - C#.
You can compile C# code on the fly, and it's very easy and cheap with the new compiler, Roslyn. Then all you need to do is define your interface so that it's easy to use for the users, and put that code in a method you can call from your code. This allows you to easily support all the various development tools for C# as well, including Visual Studio/VS Code. In the simplest form, all you need to do is make your "script" implement some base class that has all the methods you want the users to have - there's certainly better approaches, but this one is very simple, which sounds like something you're looking for.
Of course, this only makes sense if you can trust your users. Making safely sand-boxed code in C# is a lot more complicated (though certainly possible), and you'd probably be better off using some ready scripting solution.
For a large porting from VB6 to C# job I wrote a tool which uses a murder of regular expressions to analyse a VB6 code base and extract the dependencies of all the functions in all the forms, bas files and classes.
It allowed us to chop out blocks of code for the developers, generate graphs and extract all the SQL.
I could really use something that does the same thing for C# and although it would be a lot easier for C#, I don't have the time or budget to write it.
We are limited to VS2008
Does anything like this already exist?
I'm not sure but I think NDepend has this. If not, writing it yourself should be pretty straight forward using Roslyn or NRefactory
If you take a look on project Roslyn page, you'll find example which will show you about 70% of what you seem to try to achive.
Walkthrough: Getting Started with Semantic Analysis – C#
It seems you are doing some kind of "refactoring". I found ReSharper is most useful in this case http://www.jetbrains.com/resharper/
I've been playing with Java for years as a means of developing quick and easy tools for repetitive tasks. I am not a true "developer" in the traditional sense, but I have lots of experience creating a wide assortment of tools and PoCs.
Unfortunately for me, I have noticed many shops are specifically looking for experience with C#, and not so many for Java. Even here on SO, there are more questions and more followers to C# related issues than Java. My preference will always be Java over C# simply for the cross-platform compatibility, but since the languages are so similar, I believe it would be beneficial for me to cross-train. I have already dabbled in other languages and scripts (VB and other BASIC flavors, Javascript, VBScript, ASP, JSP, PHP, etc.) so adding another isn't out of the question.
My current Java environment simply consists of a text editor (primarily jEdit for its plugins and layout) and homemade scripts to compile/jar my projects. I don't like to use IDEs because I want full control over my code and don't want a program writing code for me. (I also prefer to write my own code as opposed to using any sort of external library/package, if feasible. It helps me learn and greatly reduces unnecessary code.)
Therefore, what are my options for a non-IDE C# SDK? Libraries are obviously not that important to me. I've heard of Mono, which appears to separate the functions, but haven't tried it yet. What other SDKs exist that are similar to a simple Java SDK combined with a text editor?
Using an IDE doesn't have to mean anything writing code for you. I'm not generally keen on designer-generated code, but unless you decide to use a designer (or snippets etc), Visual Studio won't be writing code for you. Of course it will create a skeleton class for you when you create one, add the appropriate method signatures when you implement an interface etc - but is that boilerplate really something you want to write yourself?
I'd also suggest that your policy of not using external libraries is a bad one. I agree that it's useful for educational purposes to sometimes reimplement something, but it means that the code quality is likely to end up being worse... why would you not want to use code that has already been used and improved by many other people? Yes, you need to be careful about what libraries you use - but you really don't want to do everything yourself... not if you want to be productive, anyway.
I often use a text editor and command line myself for simple test code (e.g. for Stack Overflow questions) but I wouldn't dream of doing that for "real" code that I plan to keep.
Honestly, a lot of C# and .NET is about learning the tools; Visual Studio gives you a lot that you wouldn't be able to do with a text editor. There's a free version, and I highly suggest you check it out! People hiring will want to know that you're familiar with the tools they'll most likely be using.
You can just start with Notepad and csc.exe, the the command-line C# compiler that ships with the .NET SDK.
However, IDE is not necessarily synonym for code generator. I would download Visual Studio Express and start with empty Console projects.
Have fun!
Don't forget you can build/assemble C# projects using MSBuild and a .sln file if you really want. But the IDEs will make life a lot easier.
The IDE will not write code for you, it will help you writing code. Using libraries will help you concentrate on what you really want to program, not the things that already have been done.
Check into AvalonEdit, the text editor component of SharpDevelop. It is an open source text editor that has classes that could implement features such as intellisense and syntax highlighting. You would only have to use as much of it as you wanted and you could embed it anywhere you would use a text box control.
If you are familiar with Ant from Java then you could also check out NAnt to do your compile phase.
As far as I know, with Visual Studio you also get a command line C# compiler, csc. You could use a text editor and manually compile your C# code with that on the command line if you really want - that wouldn't be very practical however when your project contains more than a handful of source files.
If your project becomes bigger, you could use a tool like NAnt, which is a .NET version of the popular Java build tool Ant.
I agree with Jon Skeet about that your way of working is not very practical. If you are really looking for a software development job, you'd better learn to use the tools that other developers use. An employer will also not accept the fact that you'd want to write all the code yourself instead of using libraries. By using libraries instead of writing it all yourself you save lots of time, you are reusing well-tested code and your code will be much easier to maintain by other developers.
I'd like to know good strategies for deploying a domain-specific-language which must run under at least 2 languages (Java, C#) and probably more (Python, and possibly Javascript).
Some background. We have developed and deployed a domain-specific language currently written in C#. It's deployed though a series of method calls whose arguments are either common language primitives (string, double, etc.), Collections (IEnumerable, HashSet, ...) or objects in a domain-specific library (CMLMolecule, Point3, RealSquareMatrix). The library is well tested and the objects have to comply to a stable deployed XML schema so change will be evolutionary and managed (at least that's the hope).
We hope the language will become used by a wide and partially computer-literate community, used to hacking their own solutions without central control. Ideally the DSL will create a degree of encapsulation and produce the essential functionality they need. The libraries will manage the detailed algorithms which are many and varied but fairly well known. There's a lot in common with the requirements of the DSL in Domain-specific languages vs. library of functions.
I'd appreciate ideas on the best architecture (clearly once it's deployed we cannot easily backtrack). The choices include at least:
Creation of an IDL (e.g. through CORBA). The W3C did this for the XML DOM - I hated it - and it seems to be overkill
manual creation of similar signatures for each platform and best endeavour to keep them in sync.
Creation of a parsable language (e.g. CSS).
declarative programming in XML (c.f. XSLT). This is my preferred solution as it can be searched, manipulated, etc.
Performance is not important. Clarity of purpose is.
EDIT There was discussion as to whether application calls contitute a DSL. I have discovered Martin Fowler's introduction to DSLs (http://martinfowler.com/dslwip/Intro.html) where he argues that simple method calls (or chained calls) can be called a DSL. So a series like:
point0 = line0.intersectWith(plane);
point1 = line1.intersectWith(plane);
midpoint = point0.midpoint(point1);
could be considered a DSL
There seems to be some ambiguity in the question between language and library. The terms "internal DSL" and "external DSL" are useful, and I think are due to Martin Fowler.
An "external" DSL might be a standalone command-line tool. It is passed a string of source, it parses it somehow, and does something with it. There are no real limits on how the syntax and semantics can work. It can also be made available as a library consisting mostly of an eval-like method; a common example would be building a SQL query as a string and calling an execute method in an RDBMS library; not a very pleasant or convenient usage pattern, and horrible if spread around a program on a large scale.
An "internal" DSL is a library that is written in such a way as to take advantage of the quirks of a host (general purpose) language to create the impression that a new language can be embedded inside an existing one. In syntactically-rich languages (C++, C#) this means using operator overloading in ways that seriously stretch (or ignore) the usual meanings of the operator symbols. There are many examples in C++; a few in C# also - the Irony parser toolkit simulates BNF in a fairly restrained way which works well.
Finally, there is a plain old library: classes, methods, properties, with well-chosen names.
An external DSL would allow you to completely ignore cross-language integration problems, as the only library-like portion would be an eval method. But inventing your own tool chain is non-trivial. People always forget the huge importance of debugging, intellisense, syntax highlighting etc.
An internal DSL is probably a pointless endeavour if you want to do it well on C# and Java. The problem is that if you take advantage of the quirks of one host language, you won't necessarily be able to repeat the trick on another language. e.g. Java has no operator overloading.
Which leaves a plain old library. If you want to span C# and Java (at least), then you are somewhat stuck in terms of a choice of implementation language. Do you really want to write the library twice? One possibility is to write the library in Java, and then use IKVM to cross-compile it to .NET assemblies. This would guarantee you an identical interface on both of those platforms.
On the downside, the API would be expressed in lowest-common-denominator features - which is to say, Java features :). No properties, just getX/setX methods. Steer clear of generics because the two systems are quite different in that respect. Also even the standard way of naming methods differs between the two (camelCase versus PascalCase), so one set of users would smell a rat.
If you are willing to re-describe your language using ANTLR you could generate your DSL interpreter in multiple languages without having to manually maintain them including all of the languages you mentioned plus more.
Antlr is a parser/lexer generator and has a large number of target languages. This allows you to describe your language once, without having to maintain multiple copies of it.
See the whole list of target languages here.
Although I do not want to promote my own project too much, I would like to mention PIL, a Platform Independent Language, an intermediate language I have been working on to enable the support of multiple software platforms (like Java, Python, ...), specifically for external DSLs. The general idea is that you generate code in PIL (a subset of Java), which the PIL compiler can then translate to one of many other languages, currently just Java or Python, but more will be added in the future.
I presented a paper about this on the Software and Language Engineering conference about 2 days ago, you can find a link to the publication of the PIL website (pil-lang.org), if you're interested.
Ability to escape to the implementation language in the event you need to do something that just isn't supported by your DSL, or for performance reasons (though I realize that isn't a priority).
I am researching DSL for implementing rules in a rule engine in C#, some of the rules are really complex and may change significantly in the future, so being able to escape out to C# is really useful. Of course this breaks cross-platform compatibility, but it is really just a way of hacking around edge cases without having to change your DSL.
You'd be best off writing the library in C (or some language like rpython which will generate C-code) and then using SWIG or similar to generate the language specific bindings for C#, Java Python etc.
Note that this approach won't help if you are using Javascript in the browser - you'll have to write the javascript library separately. If you are using javascript through Rhino, then you'd be able to just use the Java bindings.
It is possible to interpret JavaScript from inside a Java-program directly using the script engine, and apparently also from C#. Python can be run on the JVM and the .NET engine.
I would suggest that you investigate these options, and then write your library in a common subset of the execution paths available to the language you choose. I would not consider writing it in a language which requires post translation and conversion, since you introduce a step which can be very, very difficult to debug in case of problems.
I would like to expand on Darien's answer. I think that ANTLR brings something to the table that few other lexer/parser tools provide (at least to my knowledge). If you would like to create a DSL which ultimately generates Java and C# code, ANTLR really shines.
ANTLR provides four fundamental components:
Lexer Grammar (break down input streams into tokens)
Parser Grammar (organize tokens into an abstract syntax tree)
Tree Grammar (walk the abstract syntax tree and pipe the metadata into a template engine)
StringTemplate (a template engine based on functional programming principles)
Your lexer,parser, and tree grammars can remain independent of your final generated language. In fact, the StringTemplate engine supports logical groups of template definitions. It even provides for interface inheritance of template groups. This means you can have third parties use your ANTLR parser to create say python, assembly, c, or ruby, when all you initially provided was java and C# output. The output language of your DSL can easily be extended as requirements change over time.
To get the most out of ANTLR you will want to read the following:
The Definitive ANTLR Reference: Building Domain-Specific Languages
Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages
I have a VB5 (non .net) project that I would like to upgrade to a c# project. Has anyone have any suggestions on methods or free tools that are avalible to help me with this.
Thanks
Brad
You are better off with a straight rewrite.
What I would suggest is first convert the project to VB6. It'll be much easier to go forward from there. There are a number of tools to help you do this. There is VBMigration Partner and there is vbto. I've not tried either so YMMV.
If costs are a constraint you could try this: there is a wizard in Visual Studio that will attempt to upgrade VB6 to VB.NET. It's not 100% accurate and you WILL have to write code for things VB.NET does not support such as control arrays, etc. Once the code is in VB.NET you can use a tool like SharpDevelop to convert the VB.NET to C#. It'll be a bit tedious but i suppose all roads, no matter how convoluted, lead to Rome.
In case you were able to migrate it to VB6 you can use the code advisor to see how you can fix your project to be compatible to vb.net, then you can migrate to vb.net, in case it success, you can use this tool to convert it to c# or the Reflector.
I give it a chance of 1x10^(-100)% to work.
Good luck.
If you're about to convert VB5 to .NET (whether it's C# or even VB.NET) the fastest way is to restart from 0 your implementation so you can take full advantage of .NET Framework classes. I don't know if there are tools to do this conversion automatically.
It's rarely a good idea to do a strict conversion from one language to another, particularly when they are as different as VB5 and C#.
Theoretically, you could convert VB5 to VB6 and then VB6 to VB.NET and then VB.NET to C#, but that just sounds crazy to me as I type it.
C# is so much more powerful than VB5 that you wouldn't want to covert the code anyway. After all, it likely has a poor design due to VB's weak OO capabilities.
I'd instead recommend re-implementing the functionality you need in C# (or whatever other language you want to use).
I know there exist a conversion tools, not sure though if there are some for vb5.
However, i'd recommend performing a redesign of the project, taking advantage of the .net features unavaiable in vb5. Specially it would be good redesigning for a OO language.
Migrating VB5 to C# just to have .NET is never a good reason. I would prefer to have a good look at the assumptions and design decisions I made in the VB5 version, rethink them all, add new ideas, sketch the UI and improve it to look closer to a modern one.
Then it's a new project, I wouldn't even call it a rewrite, because so much would have changed.
I've migrated a small 1-tier VB6 application to C# and I will never do it again.
There are applications out there that do a rather good job migrating from VB6 to VB.Net.
//Magnus
I’ve done it in the past but don’t recommend it. Getting the project to work correctly after the ‘auto-migration’ was not worth the effort. I ended up rewriting the program and was better off because of it.
Having done this myself I talk about the issues involved here.
Basically as ocdecio you are looking at least a partial rewrite. You will likely need to refactor your forms to move as much code out of them as possible. You will also need to refactor any VB6 specific features to work behind a interface that you can reimplement in .NET. Notably the Graphics commands, and the Printer functions. Migration Tools are usually worthless for any serious project.