Temporarily leaving the elegance and convenience of emacs for the awkward mess that is Visual Studio
November 3, 2010 3:24 PM Subscribe
Non-beginner programmer with a unix background looking to pick up C# - What do I read?
In the spirit of rounding out my skill-set (and actually having some skills people from the real world want to pay for), I have decided I need to learn an MS-friendly language. I already have a solid background in programming in a unix/linux environment, ranging from straight C for console and X11 apps to LAMP stuff and web development to perl and bash scripting for the quick and dirty (plus things like Fortran I do not feel comfortable mentioning in public).
Having recently tried my hand at functional languages, I'm thinking C# (which I understand has a nontrivial amount of functional behavior built-in) might be both fun to learn and useful.
A project is in fact coming up where C# would be a good fit, but I don't have the time to wade through Hello World tutorials, yet can't really find my way around Visual Studio and the MS way of doing things.
Does the hivemind have any good reading suggestions, either on-line or on paper?
In the spirit of rounding out my skill-set (and actually having some skills people from the real world want to pay for), I have decided I need to learn an MS-friendly language. I already have a solid background in programming in a unix/linux environment, ranging from straight C for console and X11 apps to LAMP stuff and web development to perl and bash scripting for the quick and dirty (plus things like Fortran I do not feel comfortable mentioning in public).
Having recently tried my hand at functional languages, I'm thinking C# (which I understand has a nontrivial amount of functional behavior built-in) might be both fun to learn and useful.
A project is in fact coming up where C# would be a good fit, but I don't have the time to wade through Hello World tutorials, yet can't really find my way around Visual Studio and the MS way of doing things.
Does the hivemind have any good reading suggestions, either on-line or on paper?
You might get better answers if you can narrow down your question a bit. What kind of project do you have coming up that you want to do in C#? Console app, GUI app, web service, website, what? Is it going to involve database integration? Is it going to involve networking or other cross-computer or cross-process communication?
In terms of visual studio, what does the project require that you want to learn about? Cross-project dependencies? Deployment? Proper file layout?
(And are you sure C# is really the best fit here? From your background it sounds like you might be better off picking up Java.)
posted by inkyz at 5:41 PM on November 3, 2010
In terms of visual studio, what does the project require that you want to learn about? Cross-project dependencies? Deployment? Proper file layout?
(And are you sure C# is really the best fit here? From your background it sounds like you might be better off picking up Java.)
posted by inkyz at 5:41 PM on November 3, 2010
The site Monsieur Caution links is good. That and the .NET info are probably the best starting points.
(BTW, having done a fair amount of both, Java and C# are 90% identical. There are a few language differences but the main thing about switching between them is learning the libraries).
posted by wildcrdj at 6:12 PM on November 3, 2010
(BTW, having done a fair amount of both, Java and C# are 90% identical. There are a few language differences but the main thing about switching between them is learning the libraries).
posted by wildcrdj at 6:12 PM on November 3, 2010
omg you and everyone else should read CLR via C-Sharpby Jeffrey Richter ("see you at the paaaarty, Richter!")
posted by Glendale at 7:09 PM on November 3, 2010
posted by Glendale at 7:09 PM on November 3, 2010
Once you figure your way around VisualStudio, I bet you love it. VS is, hands down, the best IDE for development.
posted by tayknight at 8:20 PM on November 3, 2010
posted by tayknight at 8:20 PM on November 3, 2010
CLR via C# is not bad.
C# in Depth is a must.
When I started C#, I already knew Java, so I read a book that taught C# through Java - not bad, but then again, I learn a language in about a weekend.
C# is a pretty solid workhorse of a language. There are a fair amount of niceties compared with C/C++, but it is a bit wordy (this is somewhat better through limited type inference). The libraries are what make the language work and they are pretty good.
posted by plinth at 8:31 PM on November 3, 2010
C# in Depth is a must.
When I started C#, I already knew Java, so I read a book that taught C# through Java - not bad, but then again, I learn a language in about a weekend.
C# is a pretty solid workhorse of a language. There are a fair amount of niceties compared with C/C++, but it is a bit wordy (this is somewhat better through limited type inference). The libraries are what make the language work and they are pretty good.
posted by plinth at 8:31 PM on November 3, 2010
Response by poster: What kind of project do you have coming up that you want to do in C#? Console app, GUI app, web service, website, what? Is it going to involve database integration?
It is essentially a GUI front-end for a simple database recording business transactions: forms for data entry, import/export of data files and calling up reports. Somewhat non-exciting stuff from a purely technical point of view, so a good fit for trying out new things.
In terms of visual studio, what does the project require that you want to learn about? Cross-project dependencies? Deployment? Proper file layout?
This is exactly what I'm talking about: How do I split things up in files in a reasonable manner? What files do I need to put under version control? Can I review changes using diffs? Are there makefile-type metadata files, what are they and what do they contain? Can I use preprocessor macros to build different executables from the same source? How do I deploy libraries? What's the deal with projects and solutions?
From your background it sounds like you might be better off picking up Java.
This may be true, but everybody I'm co-operating with lately comes from a Windows-only, .net background so having some experience with this kind of thing would be very handy.
posted by Dr Dracator at 11:54 PM on November 3, 2010
It is essentially a GUI front-end for a simple database recording business transactions: forms for data entry, import/export of data files and calling up reports. Somewhat non-exciting stuff from a purely technical point of view, so a good fit for trying out new things.
In terms of visual studio, what does the project require that you want to learn about? Cross-project dependencies? Deployment? Proper file layout?
This is exactly what I'm talking about: How do I split things up in files in a reasonable manner? What files do I need to put under version control? Can I review changes using diffs? Are there makefile-type metadata files, what are they and what do they contain? Can I use preprocessor macros to build different executables from the same source? How do I deploy libraries? What's the deal with projects and solutions?
From your background it sounds like you might be better off picking up Java.
This may be true, but everybody I'm co-operating with lately comes from a Windows-only, .net background so having some experience with this kind of thing would be very handy.
posted by Dr Dracator at 11:54 PM on November 3, 2010
I'm not emacs-literate but when I'm able to I use Vim.
Using Visual Studio after being used to Vim is not a good experience , I'm guessing for the emacserati things would be similar.
The good news is that there is a plug in for Visual Studio which provides a significant subset of Vim behaviour in VS. My guess is that there will be something similar for Emacs - you might want to consider looking into that.
posted by southof40 at 1:55 AM on November 4, 2010
Using Visual Studio after being used to Vim is not a good experience , I'm guessing for the emacserati things would be similar.
The good news is that there is a plug in for Visual Studio which provides a significant subset of Vim behaviour in VS. My guess is that there will be something similar for Emacs - you might want to consider looking into that.
posted by southof40 at 1:55 AM on November 4, 2010
Best answer: The MSDN documentation is usually a good point source for Windows development. There's rarely a question on any development topic that's not answered to some degree. That includes best practices for Windows coding.
You may find reading the Structuring Solutions and Projects article helpful to at least a couple of your questions.
posted by hungrysquirrels at 9:40 AM on November 4, 2010
You may find reading the Structuring Solutions and Projects article helpful to at least a couple of your questions.
posted by hungrysquirrels at 9:40 AM on November 4, 2010
Best answer: For learning C# itself, I highly recommend C# in a Nutshell. It's a no-nonsense guide to the language and the .Net framework that will get you up to speed very, very quickly on those topics. I highly recommend this book, because by reading it, you'll have a very good idea of what there is in the language. This will help keep you from re-inventing the wheel, and will also enable you to read and understand code better. It will also make you aware of all the cool functional stuff, LINQ, etc. C# is a pretty big language, but it also seems well thought out. C# in a Nutshell also serves as a good reference. My recommendation would be to read through the first 3-5 chapters, then skim the rest, so that you know what's there. Then, when you're not sure how to do something, you at least know what the class you need might be called.
As for the GUI stuff, that depends on what you're using. Right now, WPF is the new hawtness, and I recommend it if you're looking into your options. If you're using WPF, I would read WPF 4 Unleashed, which will get you into the mindset of using WPF, and then Pro WPF in C# 2010: Windows Presentation Foundation in .NET 4 as more of a reference/advanced topics type book. If you're doing WPF, you'll also want to read up on the MVVM design pattern.
The other option for GUI would be Windows Forms/WinForms, which is the drag-and-drop thing you remember from VB. I don't know much about that. MVP (model-view-presenter) is a similar design pattern to MVVM that might be more relevant with WinForms.
How do I split things up in files in a reasonable manner?
Generally, a file should contain one class. This isn't a requirement like in Java, but it's a good rule of thumb. In a WPF app using the MVVM pattern, you will have a Models directory, a Views directory, and a ViewModels directory. In my projects, I also have a Libraries directory that has various libraries (themselves organized into subdirectories) in it. I'm not sure if this is a best practice at all, it's just what I do. When you create directories through Visual Studio, it automagically maps them to namespaces in your project, which I find useful. You might consult other resources for project organization (maybe look or ask on StackOverflow), as I've kind of made mine up as I go.
What files do I need to put under version control?
You can see what I have under source control on this open source .Net project of mine. In short, you put the solution (the .sln), the projects (.csproj, .vbproj), any code (XML, C#, etc.) including generated code, and any 3rdparty DLLs (you put these in so that they're in a consistent place and you have everything you need to build the project in the repo) in the repo. You do not put the .suo or anything under bin or Obj (these are the output directories for the compiler). If you're familiar with git, my .gitignore file in that repo may be instructional.
Can I review changes using diffs?
Yes! Code is code, text is text. If you're using source control, it will work just like you'd expect. If you're not using source control, now's a good time to start!
Are there makefile-type metadata files, what are they and what do they contain?
The make system is called MSBuild, and uses XML configuration files. Generally speaking, Visual Studio will handle all this for you, such that all you have to do is hit "Build" and it will Build. Visual Studio, by the way, will seem huge and kludgy after using Emacs, but it really does make your job a lot easier. If you're using Visual Studio, the information to build a project is in the .csproj file. You can see mine here: from that same open source project Note that I didn't write any of that, it was all generated by Visual Studio. At some point, you may need to write your own msbuild files, but I'm not sure when that point comes. I wouldn't do it unless you had a specific reason though.
Can I use preprocessor macros to build different executables from the same source?
You can use #ifdef s to conditionally include or exclude parts of code. You cannot do C-style macros that actually contain functionality. If there are other uses cases for pre-processor magic you're wondering about, feel free to ask.
How do I deploy libraries?
You deploy libraries as .dlls that sit in the same directory alongside your executable. When you reference a dll within Visual Studio, it will set it so that when your program compiles, the dll is automatically copied to the output directory, which is exactly what you need. There is also something called the GAC, which is a system-wide registry of DLLs. I do not know under what circumstances you need to use this.
What's the deal with projects and solutions?
A project is something that compiles down to a .dll or .exe. For example, suppose you have a library that is going to be shared between 3 applications. The library itself would be a project producing a .dll, and each application would be a project producing an .exe. A solution is what you would use to group these all together.
Feel free to ask any more questions you have.
posted by !Jim at 11:49 AM on November 4, 2010 [1 favorite]
As for the GUI stuff, that depends on what you're using. Right now, WPF is the new hawtness, and I recommend it if you're looking into your options. If you're using WPF, I would read WPF 4 Unleashed, which will get you into the mindset of using WPF, and then Pro WPF in C# 2010: Windows Presentation Foundation in .NET 4 as more of a reference/advanced topics type book. If you're doing WPF, you'll also want to read up on the MVVM design pattern.
The other option for GUI would be Windows Forms/WinForms, which is the drag-and-drop thing you remember from VB. I don't know much about that. MVP (model-view-presenter) is a similar design pattern to MVVM that might be more relevant with WinForms.
How do I split things up in files in a reasonable manner?
Generally, a file should contain one class. This isn't a requirement like in Java, but it's a good rule of thumb. In a WPF app using the MVVM pattern, you will have a Models directory, a Views directory, and a ViewModels directory. In my projects, I also have a Libraries directory that has various libraries (themselves organized into subdirectories) in it. I'm not sure if this is a best practice at all, it's just what I do. When you create directories through Visual Studio, it automagically maps them to namespaces in your project, which I find useful. You might consult other resources for project organization (maybe look or ask on StackOverflow), as I've kind of made mine up as I go.
What files do I need to put under version control?
You can see what I have under source control on this open source .Net project of mine. In short, you put the solution (the .sln), the projects (.csproj, .vbproj), any code (XML, C#, etc.) including generated code, and any 3rdparty DLLs (you put these in so that they're in a consistent place and you have everything you need to build the project in the repo) in the repo. You do not put the .suo or anything under bin or Obj (these are the output directories for the compiler). If you're familiar with git, my .gitignore file in that repo may be instructional.
Can I review changes using diffs?
Yes! Code is code, text is text. If you're using source control, it will work just like you'd expect. If you're not using source control, now's a good time to start!
Are there makefile-type metadata files, what are they and what do they contain?
The make system is called MSBuild, and uses XML configuration files. Generally speaking, Visual Studio will handle all this for you, such that all you have to do is hit "Build" and it will Build. Visual Studio, by the way, will seem huge and kludgy after using Emacs, but it really does make your job a lot easier. If you're using Visual Studio, the information to build a project is in the .csproj file. You can see mine here: from that same open source project Note that I didn't write any of that, it was all generated by Visual Studio. At some point, you may need to write your own msbuild files, but I'm not sure when that point comes. I wouldn't do it unless you had a specific reason though.
Can I use preprocessor macros to build different executables from the same source?
You can use #ifdef s to conditionally include or exclude parts of code. You cannot do C-style macros that actually contain functionality. If there are other uses cases for pre-processor magic you're wondering about, feel free to ask.
How do I deploy libraries?
You deploy libraries as .dlls that sit in the same directory alongside your executable. When you reference a dll within Visual Studio, it will set it so that when your program compiles, the dll is automatically copied to the output directory, which is exactly what you need. There is also something called the GAC, which is a system-wide registry of DLLs. I do not know under what circumstances you need to use this.
What's the deal with projects and solutions?
A project is something that compiles down to a .dll or .exe. For example, suppose you have a library that is going to be shared between 3 applications. The library itself would be a project producing a .dll, and each application would be a project producing an .exe. A solution is what you would use to group these all together.
Feel free to ask any more questions you have.
posted by !Jim at 11:49 AM on November 4, 2010 [1 favorite]
Response by poster: Half a year later I find myself being the main developer on one C# application that is happily up and running and have another one in the pipeline, somewhat delayed but coming along nicely.
I have to say I was pleasantly surprised by C# - there's a lot of powerful functionality in there (even though the lack of parametrized constructor constraints for type variables is cramping my style somewhat). Interestingly, one part of my background that really paid off was playing around with Haskell, very useful for grasping the more abstract features.
Thanks to everyone that answered - your answers really helped put me on the right track.
posted by Dr Dracator at 1:34 PM on August 29, 2011
I have to say I was pleasantly surprised by C# - there's a lot of powerful functionality in there (even though the lack of parametrized constructor constraints for type variables is cramping my style somewhat). Interestingly, one part of my background that really paid off was playing around with Haskell, very useful for grasping the more abstract features.
Thanks to everyone that answered - your answers really helped put me on the right track.
posted by Dr Dracator at 1:34 PM on August 29, 2011
« Older where to find fall colors in nov (in SE USA)? | Why won't Windows 2008 play with Java? Newer »
This thread is closed to new comments.
posted by Monsieur Caution at 5:36 PM on November 3, 2010 [1 favorite]