I'm starting out on a new project and a team member has decided to use C# as the implementation language. I don't have a lot of experience in C#, but a brief reading shows that it's very capable of being a complete cross-platform vm. Beyond the language, I've been having trouble selecting tools and workflows for managing the code as the project grows. It should be fairly small (<10K lines) but I would like to have the ability to generate documentation as the project grows, manage any external dependencies that we decide to use, and automate builds and testing. I am wondering what tools are commonly used or considered best practices for this language.
I am mainly concerned with how would a build system potentially work on *nix as well as windows? Are there C# specific tools or is Make more common? In addition, I'd like to use a dvcs, but it doesn't look like Visual Studio and MonoDevelop support the same ones. What's the common vcs of choice for C#? For testing sort of Unit testing is available for C#/Mono? Finally, I know that there are good doc generators, but with the question of the build system, I would really like to have that just be a single step in the build similar to how testing is a step. Normally I'd automate with Hudson, but I am wondering if there is something more specific to the platform.
Overall, I'd love to see a solution that provides a decent workflow on both windows and *nix without a heavy admin burden. I am pretty sure this is the holy grail of project management, so anything that puts me on that path is awesome.
In a project I work on, we use Visual Studio 2010, MonoDevelop/XBuild, Git, and monodoc. Project files created by Visual Studio 2010 can easily be read by MonoDevelop and XBuild. Also, Git is an excellent VCS for distributed development (I especially like its branching). Monodoc, with some tweaking of command line parameters, can generate documentation from XML comments in code.
You can use any dvcs you'd like with it. MonoDevelop (at least in the trunk, not sure if it has been released yet) as Git support built in. There are some plugins for Visual Studio that give you Git too.
Either way though, you don't need your source control to be integrated within the IDE, infact I prefer it not to be and use Git from TortoiseGit if I'm in windows, or from the command line on OS X (although I'm looking at Gitti for the OS X side).
For build, I would suggest TeamCity, since it supports up to three remote agents allowing you to build on Windows/Linux/Mac with the free version.
For build I'd use NAnt, although xbuild under mono works with solution files so that might be easier rather than maintaining two build scripts. I like NAnt for CI simply because I find it easier to break apart into build, test, cover, package, deploy etc.
I've found that the combination of MonoDevelop, Git, TeamCity and NAnt gives you a few nice cross-platform development setup.
I suggest you try to use one IDE mainly. Most Mono IDEs support Visual Studio formats I guess. At least SharpDeveblop does.
http://mono-tools.com seems the correct way to develop for .NET and Mono only in Windows (not free). I think this is the best option if I ever take developing for mono seriously ina commercial environment, but not 1005 sure.
http://sharpdevelop.com looks promising too, but still fells like the poor man option.
http://monodevelop.com/ is the way to go for developing for Mono in Linux.
For DVCS you can always use Tortoise stuff and be IDE independent. git works great in Linux and TortoiseGit on Windows is very nice. However, it terms of fame, SVN (not DVCS of course) is still dominant, especially it's client can connect to TFS via bridge. Mercurial and Git are starting to take place in C# community though.
CruiseControl.Net is a pretty good build / continuous integration system. It can integrate a load of applications into the build process; we use NAnt for builds, NUnit unit tests and FXCop for code analysis.
Cake (C# Make) is an open source build automation system with a C# based domain specific language that can do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages. It has tons of other built-in functionality and can easily be extended with custom code. It's available for Windows, Linux and OS X and can be used with several continuous integration systems such as AppVeyor, TeamCity, TFS, VSTS or Jenkins.
Related
In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment - version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I'd prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn't update automatically, and I'm wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don't want. I assume I can create this as a patch somehow, but I've not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I'd really rather approach one at a time.
Any thoughts for the best way to get over these two issues?
I don't have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I'll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it's a horrible road to go down. Even Microsoft knows it sucks and that's why it won't be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it's critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn't what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.
If these are released applications, then the installer method is fine. If you are adding libraries through this method, and not necessarily the actual application, then something like NuGet (package manager) is an option. NuGet itself is a bit infant and needs to grow up a bit, but I think it should fit your basic scenario.
If you have published software, a bootstrap on the client that calls for updates and then runs the update installer is a good pattern.
The basic answer is you have options, depending what bits you are employing and should take advantage of the one(s) that fit your needs.
I've already looked at C#: Making an Installer that installs both a WPF application (ClickOnce) and a Windows Service but that never answered my question. I have a similar set up: a WPF application and a Windows Service. I'd like one installer that installs the Windows Service first, then installs the WPF application. Also, it has to be able to open firewall exceptions as well.
Anybody have any experience with any products that can do this? I've got the feeling that InstallShield Premier can do this but I'd prefer not having to spend $500 or so for a license.
Thanks!
Have you looked at WIX? It's an open source tool for building MSI setups. It's pretty well supported. I haven't used it to do what you are asking, but a quick search did reveal a firewall settings extension for WIX: http://www.joyofsetup.com/2008/05/17/new-wix-feature-firewall-extension/
Have you looked at Nullsoft Scriptable Install System(NSIS)?
A little while ago, I decided to take a little utility I wrote and make redistributable1. I looked at a whole bunch of standard installer options (i.e. VS IDE vs. different flavors of InstallShield) and one thing I didn't like is that they could all do trivial things, but if you needed something just a tad more complicated, the best option was non-free InstallShield or you are out of luck.
Then I came across NSIS. From my initial impression, it looks to be a full blown installer builder. It supports most features, even complicated ones and it is open source. Even for things that the product itself doesn't support, there's a strong community of other developers that post their own scripts and add-ons.
It is probably not as easy to use as InstallShield (I remember IS had visual and very friendly IDE). This one is more scripted, so you need to understand their language. But it's not difficult, I was able to ramp up and create and install package within one day.
1-If you wish to see what NSIS script looks like, you can follow GitHub link in my profile. The project is called "Droppy"
I am wondering how can I make a setup project for each of these projects
Asp.net mvc 2.0
C# cmd line
Application C# web-service
I am using VS 2010 ultimate and I know that I can use the the free edition of install shield for at least the cmd line application. I am not sure about the other 2. I also know about the setup project that you can use. I just need a lot more than the basics so I am not sure how to make either one do these things.
So here is some criteria that each of my setups should be able to do.
Asp.net mvc 2.0 criteria
free (I really don't want to pay for an installer - you can list them just so I am aware of them).
Terms of service
Ability to force a user to setup certain settings. Like connection string, smtp settings. So they should be able to type it in through the setup wizard and the web.config should be updated based on this.
When it installs the stuff it should all be .dlls for all the C# code.
C# cmd line criteria
All criteria as above
I am not sure if this has to be done in the code but I have a html file that contains a template for a message. The path to this file is in the web.config so I a person needs to set this path each time they install it. I tried to do this in code but I could not figure out how to make it find the right path in development and the right path in production. It seems like If you run in VS the path is different.
Web-service
Pretty much everything I covered in the first 2 ones.
Thanks
If I were you, I would choose WiX as a platform for your installers for all these applications. Some reasoning behind this:
it is XML-based, that is, friendly to source control, diffing and merging
it has rich set of tools for most of scenarios you might need (harvesting lots of files, creating upgrades and patches, creating multi-lingual installs, etc.)
it is free and open source
it is production-ready (at least, version 3.0 - later versions are still in beta)
it is used by Microsoft to create installations for such products like MS Office
it has rich community at wix-users#lists.sourceforge.net and StackOverflow
it integrates into the VS like a charm
it is friendly to build engines like NAnt and MSBuild
VS setup project is not my choice because:
it is very limited in set of features-
it encourages bad practices like Installer classes
finally, it was retired by Microsoft
I'm not familiar with InstallShield Limited edition, though.
Hope this overview will help you finding the best option for your case.
I'm looking into Mono and .NET C# and we'll be needing to run the code on Linux Servers in the future when the project is developed. At this point I've been looking at ASP.NET MVC and Mono.
I run an Ubuntu distro and want to do development for a web application, some of the other developers use Windows and run other .NET items with Visual Studio.
What does Mono not provide that Visual Studio does?
If running this on Linux later shouldn't we use MonoDevelop?
Are there some third party tools or add-ins that might be an issue with Mono later?
What does Mono not provide that Visual Studio does?
MonoDevelop is presumably what you mean here. MonoDevelop offers cross platform development on Linux, Mac OS X, Windows based on GTK. However it is not as polished as Visual Studio for obvious reasons - it's 3 people making it, not hundreds. It has some nice features, especially its source control plugin architecture. However as Visual Studio Express is free there aren't many advantages on Windows to using it.
It uses the same .csproj and .sln format as Visual Studio, however the XML docs format is different.
If running this on Linux later shouldn't we use MonoDevelop ?
As I mentioned above, the project formats are inter-operable.
Are there some third party tools or add-ins that might be an issue with Mono later?
Unlike Visual Studio, there aren't a huge wealth of add-ins for Monodevelop. The ones that you use in Monodevelop won't effect your .csproj files at all, as anything Visual Studio cannot read it generally ignores.
As people have said don't confuse Mono for MonoDevelop. MonoDevelop is an IDE for Mono that originally came from (forked) SharpDevelop.
Mono is the cross platform framework that 'apes' the Microsoft CLR and framework libraries.
I don't have much experience in this area but...
The Mono Project Roadmap has an overview of features that are new, upcoming, and not present in Mono compared to MS.NET. Even where Mono has the same classes as .NET, note that compatibility is not 100% (although that is generally their goal). I'm not sure if there exists a comprehensive list of things missing in Mono.
MonoDevelop is now available on both Windows and Linux so you're probably best off using it. However, MonoDevelop does appear to use the same project file format as Visual Studio and SharpDevelop, so you could make an attempt at mixing IDEs.
Of course, when using 3rd-party .NET libraries, note that many of them have not been tested with mono, and in particular anything that uses P/Invoke will not work on Mono for Linux. However, most incompatibilities with mono are minor, and if you stick with open-source libraries you can always fix any incompatibilities you run into.
You might also take a look at Mono Tools for Visual Studio. It lets your visual studio developers target and test with the mono platform.
You're aiming to always have support, and/or primarily use the software on Linux, correct? This is actually a question I asked the Mono developers at a conference a little while back, and it basically boiled down to what you want to do with it.
If you want it to always work on Linux, then use Mono. If you only care about Windows, then use Visual Studio.
If you're using Mono, then use MonoDevelop across all developers. It'll just make life a lot easier later on, and it'll make sure that whatever you write in the one will work for everyone.
Unfortunately, I do not know the answer to the exact limits/advantages of Mono vs. .NET, aside from .NET being further ahead, and Mono playing catch-up, nor about different addons.
If none of your developers need to develop on Mono for certain features, I suggest you all use Visual Studio on Windows. Then test the applications on Mono via
Mono Tools for Visual Studio
manually copy the binaries over
check out the code on Linux and build in MonoDevelop.
Personally I experienced a lot of small troubles when I tried out the third way, but luckily I am capable of finding workarounds.
It is only when you touch Mono, you know which part of your application needs to be tuned.
http://www.mono-project.com/Start
If you can help it, it'd recommend avoiding the Mono implementation of Remoting. There seem to be some unexpected hiccups and debugging it is not straight-forward.
We had a very Remoting heavy product that we tried to port to Mono so we could support Linux. Due to being unable to resolve the Remoting issues, we eventually had to abandon our attempts at supporting Linux altogether.
Caveat: my experiences may be outdated. See comments below
You don't need MonoDevelop in order to run ASP.NET program in Linux, make a shared folder on your development server (VMWare'd or real one), test often so you can easily work-around what's missing from Mono
That's the same approach I'm using in my .NET Remoting program I host on Ubuntu server. But I do the reverse, since I'm a solo programmer, I make a shared folder on my Windows development machine, then access that shared folder on my Ubuntu test server (vmware'd). On ASP.NET stuff, if the changes don't reflect on your Ubuntu test server, in Terminal just touch the Web.Config file in your Ubuntu test server. i.e. touch Web.Config, then refresh the page
Mono has a fully functional implementation of ASP.NET. This includes full support for ASP.NET Web Forms and Web Services. This essentially means that more or less any ASP.NET application that you have developed using with the .NET Framework will work with Mono. Obviously there might be changes needed, such as data access changes, removal of any
reliance on .NET Framework BCL types . Mono- Oracle users-.Net Programming C# : ubuntu 11.04
Time to ask the pros, since I can't find a good answer anywhere else and I'm venturing into a side of the world that I'm just learning.
I'm in a primarily open source shop that has recently begun taking in a lot of internal tools and partners that are .Net based. That got me to thinking that I may be able to utilize the best of both worlds by leveraging C#/mono in certain spaces. On a small scale I've been very successful and it's working great. However, pressing 'Build' and scp'ing the exe into place isn't going to scale well.
I'd like to step it up a bit and get some more resources behind it, so here's my question; what are the baseline resources I need to establish a good dev/testing/staging environment.
I don't need uber-detailed information and I'm willing to consider both commercial and open source solutions, I guess I'm more looking for good advice on resources. 99% of the items developed on either side of the OS line will be services.
What sort of Unit/Regression testing tools are recommended, is NUnit the standard?
What sort of deployment mechanisms are recommended for service level software?
What, if any, additional tools have you found useful or indispensable during your development/design work?
The first 2 items are of interest since they are the last things I'm lacking before I have workable, repeatable development and deployment process.
You might want to look into http://go-mono.com/monovs/
It will alow you to debug on Linux from within Visual Studio.
The unit testing framework in Visual Studio is rather good as well,
but if you use the standard or free version of Visual Studio, NUnit is a good option as well
(And there is the option of Visual Studio integration)
Aside from that I've come quite attached to Refactor Pro (and other products by that company)
http://www.devexpress.com/Products/Visual_Studio_Add-in/Refactoring/
As for scp'ing the files to your linux/mac machines, it might be easier to
configure MSBuild to do that for you automatically.
This might help: http://bartdesmet.net/blogs/bart/archive/2006/04/13/3896.aspx
Many more msbuild tasks can be found here: http://msbuildcontrib.codeplex.com/
I hope this helps.
For build and deployment you might give NAnt a try. It'll handle your builds, and has tasks for running your tests, doing clean SVN checkouts, zipping up releases, that kind of thing. You can embed C# too. Grab the nightlies rather than the releases and don't worry too much about the lack of recent activity. Also the nant-contrib project is full of additional goodies.
Another option is to try msbuild (I believe there's a Mono equivalent, although I'm not sure to what degree). Truth be told there's not a lot of difference between the two.
I have built effective build/test/deploy infrastructure with the following:
NUnit
CruiseControl.NET (or CruiseControl)
NAnt (and NAnt Contrib)
or MSBuild (depends on your environment)
We also use subversion to manage both source control, as well as deployment (for things like CMS and website systems)
A few of the build tools we use are:
Simian
NCover
NDepend
Powershell (for both build automation as well as deploy automation and machine control)
Of course any of these tools can be substituted for other tools you like (perl, python, ruby, Ant, etc).
This is roughly how I've set up my environment at work:
I use NUnit as a unit-testing platform
I use TestDriven.NET as a plugin to easily run my unittests from within my IDE
I've set up a separate computer, which runs CruiseControl.NET
This CruiseControl.NET computer checks my source-repository on regular times. When it sees that something has changed, it gets the latest version from the source-repository and builds it. It also performs unit-tests, and runs fx-cop over the targets.
Next to that, i've configured it so that it performs a nightly build as well. This does roughly the same:
When something has changed during the day:
remove every file that exists locally
get the latest version from the source repository
build it
run unittests
run fxcop
create documentation using sandcastle helpfile builder
when the build was successfull, copy the build output to a separate folder which is named 'build-yyyymmdd'.
I've setup my source-repository so that I can keep different versions (branches) from my project.
In short, my source-repository looks like this:
I have a folder which is called
'devtrunk', which contains the actual
codebase. (On which I'm actively
developping)
I have a folder calles 'releases'.
Every time I release a new version, I
make a branch of the trunk, and I put
this branch in a new folder under
'releases'. This allows me to fix
bugs in a version that has been
released, without disturbing my
actual work on the trunk.
Since I'm working on the Windows platform, I use MSBuild to create my build-scripts (which are executed by Cruisecontrol), but, you can use NAnt instead. (Which I've used as well).