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.
Related
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/
So far I use to develop in Java. Java is multi-platform (now works on Android!), has a very powerfull VM and is open, well behaved, etc. But is also old and seems to be stopped on time in terms of language features. Scala and Gosu are nice replacements, but I don't like Scala syntax and Gosu is very immature and unlike to win from Scala. All this makes me think about moving to C# at least for web development! Phew!
One thing that is quite important to me is IDE support. Right now I use Eclipse for Java, and my favorite features are these (most important first, somewhat):
Full code navigation (call hierarchy, show variable reads & writes, inherited members).
Incremental compilation (which means fast compilation).
Many kinds of errors are detected and underlined before compilation.
Many intelligent quick-fixes (can fix/write many code for you and quickly rename elements and refactor references).
Intelligent and configurable code completion. Display hints even for unimported packages/classes.
Over 15 kinds of refactorings, all of them very useful.
Over 15 options of source generation (add unimplemented methods, generate getters and setter, generate delegates).
Configurable code formatter, even for code fragments (select code then format).
Debugger supports hot code replacement and "Drop to Frame" so I can go back an check other things without full program startup.
Code cleanups (remove unnecessary parenthesis, remove unnecessary "this" references, etc).
Very decent, autonomous and seamless CVS integration, with integrated file comparison and computer-aided merge.
Very nice tools for web development (server deployment, JavaScript and HTML editor with formatter).
Tons of plugins (code coverage analyser, memory dump analyser, eGIT).
Which of these features are available in Visual Studio for C#/ASP.NET? If I can get some by adding a cheap plugin, please tell.
Well, I like Visual Studio a lot more than Eclipse. I have only used Eclipse for minimal Java programming and Action Script. Visual Studio can do every thing you listed and if you combine it with a paid plugin like Resharper or CodeRush, you get a lot more. Why don't you download Visual Studio Express and play around with it? That would be much better than getting an answer from a very biased C# dev.
VS2010 with the addition of ReSharper has most of these things. I can't speak to CVS, but it does have fine SVN integration.
I started using VS about six months ago after a few years of Eclipse, and it works pretty well.
Nothing is cheap in the VS world compared to Eclipse.
I want to write my first Visual Studio 2010 add-in. My aim is to create an add-in that helps to automatically generate code for things like:
implement superclass constructors
create delegation methods for composed object
etc.
Of course, in order to know what to generate, my add-in must have a knowledge of the code-file the user is going to insert generated code into. (classes, base-classes ...)
My first thought was to use a C#-parser. Is this the right way to go? Isn't there any .NET-Framework part, COM-Object or whatever "built-in"?
Thank you in advance.
P.S: Is noticed that CSharpCodeProvider's class Parse() method has not been implemented by Microsoft yet. -_-
You can get a lot of info from the MS Visual Studio Extensibility site. This post from the Visual Studio blog may also get you started with dealing with the in memory code file.
You could start by looking at EnvDTE, which will help you browse through project files and code trees already parsed and analyzed by Visual Studio, as well as modifying them. EnvDTE is pretty basic and error-prone (for the few times I used it). Finding good in-depth tutorials is also difficult.
If you're trying to implement such features yourself, good luck, it's definitely doable but the learning curve might be quite steep. Otherwise, you could have a look at ReSharper which already implements the features you're trying to code (and much more). Plus it also has a very well designed API compared to EnvDTE (although not very well documented), allowing to use its internal C# parser / analyzer.
What's the fastest way to convert an existing Vb6.0 win-based application into a c# win-based?
The core language is so different, that I would have to say start from scratch, and copy only the complicated code bits. If you start from scratch you won't have to deal with all the VB6 problems, while utilizing all the C# power.
VB6 has no real classes or OOP, which makes very different from C#. Also, there is very little control on the event manager (SubClassing).
So, start from zero, copy the UI layout, and think about how would I implement this in C# in the first place, it will make your life easier.
I think the fastest would be to convert it to VB.net. Check the following question for this answer
VB6 to VB.net conversion
ans then converting it to c#. But I feel converting manually will be the better option as you can re engineer the application and may be make it simpler.
Converting the code from Visual Basic 6 to C# should best be done using an automated migration tool, like ArtinSoft's Visual Basic Upgrade Companion, which supports migration to C#.There are several reasons for this suggestion, aside from my experience with the tool.
First, even if you migrate from VB6 to VB.NET there are several language specific features in VB.NET that will not translate directly to C#. So even if you're using a VB.NET to C# converter you'll have to handle these special cases (or find a tool that handles them for you). These can include optional parameters, AddressOf functions, Visual Basic Compiler assisted operations, like Information.Err(), and Unstructure Error Handling to Structured Error Handling using Try / Catch statements. Another thing to consider is that the VB.NET compiler is limited to showing only 100 compilation errors, and compilation errors can be quite common when migrating. When moving to C#'s the compiler and other code analysis tools like ReSharper can give you a better picture of the challenge ahead, and help you detect common compilation error patterns.
Second, by migrating directly to the target language you can focus on using the features available for that language from the start, no intermediate steps. Otherwise, you'll basically end up doing two migrations when you could have focused on just one.
Third, as renick stated even though migration tools can produce hundreds or thousands of issues, most of these have relatively easy solutions. Some of them can be fixed using a find & replace function. Commercial solutions have the added advantage that they support the migration of third-party UI controls to .NET equivalents.
Also a migration can be much faster than a rewrite, you still have to write code but only for the areas where there are issues.
Granted there are applications for which a migration is not an option, but for those that fit the use case for a migration, it's a very effective means of switching platforms. You shouldn't discount the option right off the bat.
Total rewrite. MS has some migration assistance, but I believe it's VB.Net only. But why look at porting, surely you'd be better off now rewriting the app, and just interop if you have any legacy parts that you need to keep alive. And only migrate the best bits. Use this as a chance to truly improve the application.
If you need it quickly; then don't go hand cranking it - you'll miss stuff out and tear your hair out!
I investigated this product a couple of years back and I felt this product was the best. it converts from VB6 to C#. They have a free trial too.
Try ArtInSoft. This company will migrate your VB 6 code directly to C#.
I intend to write a small application to scratch a personal itch and probably make the life of some colleagues easier. Here is what I have:
10+ years of experience in C
Plenty of experience in programming against the Win16/32 API in C from the Win3.1 to 2000 days.
C library written by myself already doing about 75% of what the application shall do.
What the application shall do:
open a binary, feed it into the mentioned library.
take the resulting text output and feed it into a new Excel Workbook.
apply some formating.
integrate nicely with the Windows environment (availability in "Open With...", remember some stuff using the registry etc.)
(maybe later) before giving the CSV data to Excel, parse it by looking up the meaning of some values in an XML file.
Except for the XML parsing part I have done all of that stuff before including COM / Office Automation in C/Win32. There is a lot of boilerplate code involved, but it is doable and the result will be a pretty small application without the need for an installer.
So why even think about C# / .Net?
no experience with parsing XML
the promise of less boilerplate code for the Windows and Excel stuff (yes, I have done C++ with OWL, MFC, ATL etc. but I am not going there anymore - not for free/fun)
Since I have also experience with C++, VB(not .Net) and a little Java / Objective-C I suppose learning C# will all be about the .Net libraries and not actually about the language.
My considerations so far:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net.
My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
Please advice.
Update: one thing I forgot to mention explicitly is that I am also worried about easy deployment of the tool to my co-workers. With Win32 I am pretty sure I can come up with an EXE file < 1Mb that can be easily emailed and does not require installation. With .Net not so much. Can I create the necessary MSI or whatever in Visual Studio Express (free) or do I need 3rd party tools?
as others have your question mostly covered, I'd just like to quickly comment on your considerations:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Totally agreed. It is definitely fun and usually it does result in less code. The investment you make now will certainly benefit you in future projects. It is way faster to program in .Net than in C. Not only it is easier, but it is also safer. You are isolated from many programming errors common in C mostly related to memory mismanagement. You also get a very complete managed API to do stuff you would usually need to build your own framework.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
Hence your indecision. :-)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net. My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
.Net is an entirely different beast from VB. Most of the things you wouldn't be able to do in VB, or at least do them easily, are supported by .Net. For instance, Windows Services are a snap to build in .Net. Socket programming is also supported, but there are very few reasons to do it yourself, as you've got loads of communication APIs with .Net. You've got web-services, .Net Remoting, MSMQ management, and more recently WCF. Proper multithreading is supported by .Net, unlike the idiotic apartment model in VB. In case you really need to go low level, you can also actually use pointers in C#, inside of unsafe code blocks, even though I would never advise to do so.
If you really need to do things in C, then integrating is also relatively easy. You can create COM objects and use interop to work with them from .Net. You can also interact directly with plain ol' dlls using DllImport. Using www.pinvoke.net makes it easier.
When I developed in VB, sometimes I also had to go back to C++ to do stuff that I wasn't able of doing in VB. Since I began programming in .Net, the only extremely rare scenarios I would need to go back to C++ were when I needed to use legacy COM components that used types I was having a hard time to marshal via interop. I wouldn't worry about history repeating itself.
If you're using COM, you may be interested in using C# 4.0 instead of earlier versions - the downside being that it's only in beta. But basically it makes COM stuff somewhat less ugly for various reasons.
I'd expect there to be plenty of good C libraries for XML parsing by now. I would expect the main benefit to actually be the knowledge gained. I doubt that you'll actually produce the code faster for this project, but the next one may well be a lot quicker.
How much do you care about learning new stuff?
It sounds like an ideal project for learning C# & .NET.
You know most of what you need to do so you can use that to gain a base level of understanding of C# & .NET which you can then apply to the stuff you need to learn.
As Rune says though, a key driver could be the timescales. If this is something you need in a hurry then coding it in C & using win32 directly might be the answer.
Sorry I couldn't be more definite.
I think you should use C#. With your experience the learning curve won't be too steep. The code will ultimately be cleaner (and less of it) than you probably could with C/Win32.
There is probably going to be no problem using your existing C-library with the [DllImport] attribute.
It depends. :-) It depends on whether you want to do this quickly or if you want to learn something new. It depends on whether you will be the only maintainer of the code or if others will maintain it in the future. It depends on how complex your xml handling will be and on how complex the COM automation is.
You will probably get a working application quicker if you do it in C than in C#. Both since you have much of the stuff needed already in place and since you know C well.
But this project sounds like a good match for C# and .Net. .Net has great support for XML and COM interop is easy but clumsy in C# (much better in the next version!). So if you are interested in learning C# and .Net this would be a good project to do so.
I would definitely do this in .Net and probably C# (but I am biased). Using .Net would probably result in code that is easier to read and maintain and most probably easier to write. So if you are interested in learning C# I would suggest you go for it!
Edit:
You worry about the size of the executable if you write it in .Net. I doubt that will be a problem, for most if not all of the libraries you will use for a project like this will already be installed on your computer. 1 Mb is rather large for a .Net executable, event for a big project.
a short notice on the installation. .NET is as default xcopy-able so you wouldn't need an installer for the exe to be usable. Mail it around (or with the next release of the .NET framework optionaly leave it on a network share)
You could look at building a hybrid system that uses C++/CLI and C#. C++/CLI provides a nice bridge between the two and lets you easily split different parts of the system between the managed and unmanaged worlds.
Not sure if the setup projects are included in the free versions of visual studio. But you could use clickonce (included with the framework) or WIX (open source XML based msi creation tool).
learning C# will all be about the .Net libraries and not actually about the language
No there are many things you need to learn about the language (delegates , events , generics ...) and also it is object oriented and it manages the memory by itself and yes no pointers :)
anyway C# and .NET are great all you need is some effort to get up to speed