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.
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 have a number of legacy web controls (ascx) that contains huge amounts of inline C#. The forms contain a number of repeated and duplicate code. Our first plan is to move the code into code behinds per file, then refactor etc... were doing this to upgrade the client to the latest version of their cms
At the moment we are going to have to manually copy and paste from hundreds of files, create a code behind, copy the code, add the namespaces based on the client-side imports and then do any tidying up
does anybody PLEASE know of a tool that can do the majority of this work for us ?
Thanks
The DMS Software Reengineering Toolkit is designed to support the the construction of automated mass change tools.
It can parse HTML, and C#, (and build corresponding ASTs) and could be configured parse .ascx files. With the parse trees, one could likely generate your desired results.
Is this easy? No. is is practical? Yes, if the amount of code you are reengineering is significant, as it seems in your case.
I think your best hope here is to create a custom conversion utility. I don't know of any tools that would do this out of the box.
Use a language like Perl or Rebol which can do parsing. Rebol is the easiest.
Resharper has many features for moving and locating code for different refactorings. I don't have it installed on the machine I'm at right now, so can't verify, but it may be able to at least speed up the process and make it more full proof, even if it can't be fully automated.
I think your best bet would be to look at the Codesmith tools, or just T4 templates in general..you shouldn't need to write a custom app...though it looks like someone on CodeProject did just that : http://www.codeproject.com/KB/aspnet/InlineCodeVSCodeBehind.aspx?msg=997793
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved. So what functionality available in the .Net framework do you feel professional developers should avoid and why?
For example, .Net has a wizard for common user management functions. Is using this functionality considered appropriate for professional use or a beginner only?
One component/feature/class, etc per answer please so votes are specific to a single item.
Typed DataSets
ASP.NET *View Controls
ASP.NET *DataSource Controls
MS Ajax
jquery, and other js frameworks like prototype etc., are a more lightweight and flexible alternative. The MS Ajax controls may seem great initially, until you really need a custom behaviour out of the scope of the controls.
Microsoft themselves have recognised this to some extent in that jquery will be bundled with upcoming versions of visual studio, with intellisense support.
I think generally most controls/features that do a lot of work "behind the scenes" can cause a lot of trouble. No problem using a GridView if that layout is exactly what you want - but it very rarely is, and a Repeater is probably a better choice. UpdatePanels can save you lots of work if you want an ajaxy feel to your site, but compared with a jQuery AJAX call they - sorry to say so - suck. The user wizard you mention can be really useful during development, but if membership functionality is required in the project it should be built as an integrated part of it.
So in summary: Professional programmers should do the job themselves and write code that specifically satisfies their clients needs, and only take in ready made parts of the .Net Framework when that is in fact exactly what they need.
Thread.Abort
Here is an excellent article by Ian Griffiths about Why Thread.Abort is Evil and some better alternatives.
Remoting is generally a good one to avoid, at least if you're targeting 3.0 or above and can therefore easily host messaging endpoints in-process.
Linq To XML
XmlDocument/Xpath is easier to use, if you want strong typing to parse your document use xsd.exe or Xsd2Code.
EDIT
which one do you prefer ?
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
or, with XmlDocument and XPath
var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]");
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved.
It's the "appears to target beginners" that's the real problem.
Typed data sets are a great example. VS provides a nice simple UI to functionality that should be used only by rank beginners building extremely simple demo applications and experienced professionals who understand every nuance of the ADO.NET object model and what typed data sets are actually doing. Nobody in between those two poles should touch it, because there's a good way to learn every nuance of the ADO.NET object model and typed data sets aren't it.
Or take LINQ. It's seductively easy to write LINQ code without having a good understanding of IEnumerable<T>. But it's not so easy to write maintainable LINQ code without that knowledge.
You can think of .NET like an onion with many layers. For example the .NET compact framework is a subset of full .NET. Further there are "extra" layers on top on .NET in the form of "Extensions" which are optional installs for new features which have not yet been made part of .NET proper. An example of this would be when Microsoft released ASP.NET 3.5 Extensions which has now been rolled into .NET 3.51.
Another way to think of .NET is as a set of "libraries" you can use. For example there are a set or routines to support RegEx. If you want or need regular expressions, then you use these functions, if not you can simply ignore them. SImilary functions for things like trigonometry or security.
So I guess it really boils down to what do you need for your application? If you are doing scientific programming you may well want the trig functions. A graphical app will require functions that a console application would not. Web apps probably do not need to use the clipboard functions etc.
I really don't think there are any bad APIs in .NET, just programmers who use them in inappropriate ways.
There is lots to avoid in the WinForms library.
Avoid DataBinding to most standard WinForms controls. There are many bugs in that area which will lead to lots of head scratching. Or at least that has been my experience. NumericUpDown is a good example of this buggy mess.
Also avoid the standard WinForms controls when dealing with large datasets. They do a lot of data copying and can't deal well with large datasets.
Avoid ListView in "Virtual" mode as it is full of bugs.
In general I just recommend staying away from WinForms. If you have the option go for WPF or at least buy a good, well supported (and hopefully less buggy) 3rd party forms library.
I have a goal to build an application with UI that would run on both Windows Mobile and "normal" desktop Windows. The priority is for it to "look good" under Windows Mobile, and for desktop Windows it is OK if it distorted. Before I invest days trying, I would like to hear if that is possible to begin with. There are several parts to this question:
Is .NET Compact Framework a subset of "normal" (please, edit) .NET Framework? If not, does MSDN have any information anywhere on classes that are in .NET Compact Framework, but not in "normal" (again, please, edit) framework?
Is behavior of shared classes same in both frameworks?
Is it possible to have a single Visual Studio 2005 solution / project for both platforms? If yes, how do to set it up?
Any other comments and advice? Any relevant links?
The CF contains a subset of the full framework (FFx), but it is not a pure subset. There are actually several things available in the CF that aren't in the FFx, which makes it a bit more difficult. CF apps also, except in the most rudimentary cases, use P/Invoke. Those calls are never the same from the desktop to the device, so they are not directly portable (though with a little abstraction you can have a platform-agnostic interface).
For the most part, behavior is the same. I've seen some cases where it's not, and I recall some event ordering not always being identical though, so trust but verify.
It's possible through very careful massaging of the configurations, but I certainly don't recommend it. It's difficult to maintain and very fragile. Instead have two project files, one for CF and one for FFx. You're likely to have code file differences anyway. Add the code files as links to each project so they both use the same physical source file. I'd recommend using some form of CI to help ensure they both build at all times.
Take a look at Dan Moth's MSDN article and blog entries on sharing code assets.
P.S. I found the poster online - it'll show you all the classes that are CF. I ordered it fro Microsoft because Kinkos wanted $65 to print it out in color for me! Microsoft sent me a couple of copies free - all I had to do was ask:
http://www.microsoft.com/downloads/details.aspx?familyid=7B645F3A-6D22-4548-A0D8-C2A27E1917F8&displaylang=en
I have it hanging in my cubicle and it's a godsend when trying to remember which namespaces classes can be found in.
Nice multi-part question:
Differences between the Full Framework and the Compact Framework
The article above has links to relevant documentation about how class behavior differs (it definitely DOES differ in some situations)
Very simple! Create a single solution with a set of base functionality in a Class Library, then create two client projects (one for your desktop app and one for the windows mobile app). Finally, add references to the class library to both client projects.
Depending on the breadth of the project you are working on, you may want to check out the Model View Controller pattern. It may be a bit much for your project, but if you want to share UI behavior between projects, it can be a life saver.
Hope that helps!
CF, in general contains a subset of the classes from the regular framework - but you can't directly execute code from one on t'other. Additionally, rather than just being a subset, there are probably a few things in compact that aren't in the regular version, such as the GUI things specific for mobile devices (soft keys, etc) - assuming you are writing a winform exe, and not a web page (which might be the simplest way to get compatibility).
With some effort, it it possible to share logic code, in particular utility dlls - but they need different csproj files (since they have completely different compile-time "targets"). To reduce maintenance, you can often cheat by hacking the csproj to use wildcards, like from here:
<ItemGroup>
<Compile Include="..\protobuf-net\**\*.cs" />
</ItemGroup>
For UI, things get a lot tricker. In general the expectation would be to have shared business logic and separate UI for different target devices.
1). There is a Compact Framework so yes; And it is a subset of the full .NET framework. I've got a poster on my wall at the office that denotes a whole bunch of classes that work in CF... I don't recall off the top of my head if there are any that are purely CF, but I suppose there must be some. There are a couple of good books on the subject - one by Paul Yao that I have and another by Andy Wigley - both are available on Amazon.
2). As far as I'm aware, the classes that are CF and full framework work the same but need to be compiled for different targets.
3). I would hazard a guess that providing you only use classes that are common to both, that you could use the same solution, I don't know the extent you would have to go to make it compile for the compact device and the full version though, nor can I say with complete certainty that it can be done. I'd hazard a guess that the process isn't simple.
4). Go to your local book store and have a flick through those two books I mentioned. Like I said, I have the one by Paul Yao and it seems to cover most of what I could imagine needing on a compact device.