Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I've been using NAnt for a while but it seems to be overly complex for what I need. I was wondering if there are any alternatives around for building C# projects?
I would say once you get started in NAnt it is not THAT complex. I was missing a little bit a good "let's get me started" tutorial and everything I read felt pretty dated. A good thing is that you can use MSBuild for building the application (that is what I am using) and doing the rest with NAnt.
At least I think it is not harder than MSBuild - and for things MSBuild is easier you are free to use MSBuild for that.
This is what I am using:
<exec program="msbuild.exe"
basedir="C:\windows\microsoft.net\Framework\v3.5\"
commandline="Project.csproj /p:OutDir=..\Outdir\; configuration=Release" />
There are some great alternatives now to NAnt and MSBuild.
nRake (or just Rake)
http://jamescrisp.org/2010/03/20/nrake-rake-builds-for-net/
psake -- build automation tool written in PowerShell
http://jameskovacs.com/2008/06/27/introducing-psake/
I've personally used NAnt and MSBuild and am anxiously awaiting our upcoming switch to one of these (we haven't decided yet which). NAnt and MSBuild are not that hard to start off with, but once build scripts start getting bigger and more complicated and you need to actually debug them, they become a huge burden to deal with. It really depends on how much you're automating.
You might try FinalBuilder - it's very easy to use, although I prefer to stick with NAnt. And you always have MSBuild...
There's MSBuild, but it's no simpler than Nant.
Both are fine once you get used to the syntax.
A simpler option is to use Batch files.
Another is to use CIFactory, which provides a quick way to get a build and continuous integration server up and running.
We are looking into Cake - the biggest advantage is that it's basically C#.
With the complex process we have today it's quite difficult to maintain our NAnt scripts used to build, package and label code as well as runnig unit tests, code coverage, static analysis etc..
See also Why should you use a general purpose scripting language for your build scripts?
Since most of our code is C# we rather use C#...
Phantom is a very neat alternative for C#. I wish it was in python (more portable) and more used because the syntax is very neat and powerful.
Maven is a great build tool, it was developed mainly for the Java community but there is now a .NET plugin for building C# projects. There are fairly big conceptual differences between Maven (see wikipedia for a brief overview) and NAnt so you may want to read up on that first if you want to try it.
2 interesting features:
Mature collection of plugins for doing common tasks such as testing, doc generation, deploying etc.
Can automatically get project dependencies for you from a central repository
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Sir I am a student, I want to develop ASP.NET website. There are 2 developers in the team. So, how can I develop the website at the same time from 2 different locations (1 developer is residing in one city and another one is in another city). Please guide me about that.
Use a source control system that will allow for distributed teams. Git/Github is one of the first ones that come to mind. There is a bit of a learning curve, but it should fit nicely for your needs.
https://github.com/
Microsoft offers free TFS hosting. It integrates with Visual Studio nicely and is much more intuitive for a new comer for simple uses than Git/Github. You can find info on the free plan here: http://tfs.visualstudio.com/en-us/pricing/information/
In essence, you need source control.
Git is a common choice for this, and it's very powerful, but it can be pretty heavy for a beginner. Mercurial is similar, and something like TortoiseHg makes it somewhat easier to use (there is a TortoiseGit as well, but the complexity of Git can have you back at the command line fairly frequently). Microsoft's solution is TFS, which integrates with Visual Studio and includes a load of very nice tools.
As for hosting, there's GitHub, but like Git, that can be a bit tricky to get into. For Mercurial (and Git as well), there's Bitbucket, which is easier to use. For TFS (and now supporting Git as well), Microsoft offers the Team Foundation Service, which is free for small teams.
It depends what you're after. Personally, for a small team of relatively inexperienced developers I'd recommend Bitbucket with TortoiseHg. If you're feeling adventurous, then use Git instead (but still with Bitbucket because I much prefer their UI) because Git is well worth learning. If you really want a high level of IDE integration then TFS is the way to go, although you can replicate parts of that funcitonality with various VS plugins.
You can use;
Git with GitHub or Git with Team Foundation Service for Source Control Management
Trello or Scrum that comes with Team Foundation for User Story
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work on a team with three other developers and one business analyst writing internal business applications. We're primarily building apps in ASP.Net, and do so in a very 2003-ish way. It's like going back in a time machine. Although two of the other developers are amenable to learning new things, one of the developers is not. He's the type who thinks he's the strongest developer in town, and that if he doesn't understand a new tool within 5 minutes then he just needs to build his own. He also doesn't recognize agile development, TDD, or basically any non-Microsoft-blessed tool or method. He even considers source control from anything other than SourceSafe to be dangerous. To his credit, he's a brilliant programmer, just not someone interested in software development.
So the only way I can get consensus is if a tool is really easy to use. Once we hit a single snag, he'll lose faith in a "I told you so" sort of way.
So what set of tools should I use to get us into a modern source control system, TDD, and CI? The obvious choice in my situation seems like it would be Microsoft's TFS, but I doubt I could get our thrifty and apathetic management team to spend the extra money (they already think MSDN Pro is too much).
Basically, what is the easiest set of tools to get going with Source Control, TDD, and CI for a .Net 2008/2010 environment?
I wouldn't recommend dumping all these tools and methodologies on your team at once, take baby steps. Introduce one at a time. Some will come naturally.
There are many good choices, but I can personally recommend these:
Source control: Subversion with TortoiseSVN and Ankh or VisualSVN
Continuous Integration: CruiseControl.NET
TDD tools: NUnit + your mocking framework of choice (I use NMock, though it's a bit old-school). I agree with commenter Eric that TestDriven.NET is a must-have, particularly if you want to make this easy!
These are easy to get started with because they're all good products, reasonably to very well-documented, and widely-used (so it's easy to get help).
It's always going to be difficult to introduce new tools if you can't build a consensus. Focus on building the consensus, rather than on the tools.
SVN is very good (with Ankh and TSVN), but it can be a bit surprising to people used to SourceSafe.
TDD is a technique, rather than a toolset, so you need books, blogs, etc. For tools to support it, NUnit or MSTest. Continuous Integration is a must-have. CruiseControl.Net is pretty good (though a bit difficult to configure initially). Consider also TeamCity.
Do you have a bug-tracking system?
Oh, and if your management team is that apathetic, consider quitting.
Update: you've said that they're not so much "apathetic" as "hands-off". Question: are they really hands-off, and will they let you move things along? Or are they "status quo" -- "it ain't broke, so don't fix it, and don't rock the boat"?
I think you can make a really really good case that within the last two years Agile has become completely and totally embraced by Microsoft. I know for a fact that the Codeplex, MEF, and ASP.NET MVC teams are quite steeped in it. I also think that visual studio and parts of the windows 7 team are Agile. Also consider that Visual Studio 2010 includes out-of-the-box refactorings that don't really make much sense outside the context of TDD and that Agile is the default project management template for TFS and a picture of a corporate culture that is quite different from the one of years past starts to emerge.
As for specific tools. TFS is OK for source control but I find it very heavyweight and finicky. Others have mentioned Subversion but if you're worried about MS blessings you might have better luck jumping straight to Mercurial. Its a more advanced SCM but it is now supported natively by Codeplex and has excellent windows integration. I've never used it but I am in deep tool-love with it's cousin git.
Test driven development: Start with MSTest, its not as slick as anyone would like but its not the worst thing in the world. I would also recommend MbUnit which has all of NUnit's features along with some good support for the integration tests that you will probably be writing by accident as you are starting out with testing. Oh, and if you have customization freak I would urge him to look at XUnit.Net.
Mocking: The choice is basically Rhino Mocks or MoQ. Here's a quick intro I wrote for Rhino Mocks that goes over all the basics. That being said, the trade off seems to be more documentation for RM versus a very mildly less error prone syntax for MoQ.
Test Runners: If you start out with MSTest you'll notice that you can get a significant speed boost in your test runs by using TestDriven.Net, resharper or coderush rather than the built in test runner. That being said, don't underestimate the standalone test-runners. They can be quite good every once in a while. I heavily recommend Gallio Icarus runner which comes with MbUnit.
I want to echo what George Mauer has said and suggest starting with MSTest for your unit testing. It's right there in the box to begin with Visual Studio, this will help in your cause as it's "MS blessed".
I would start with unit testing and take it from there, after a few months of "look how easier our life is now we have these tests automated" I'd take it up a notch. Consider adding something like Selenium or WatiN to the mix. Once you're rolling with that, get your CI server up. "Wouldn't it be great if we didn't have to start off all these tests manually?..."
I guess a decent SCM might be a sticking point. SourceSafe is better than nothing. Perhaps start using Mercurial or Git yourself? Show those open to the change the benefits, eventually your stubborn dev will come around when others around him are wanting to switch. Hopefully, he'll find it harder to shout if he's in the minority.
Check out http://www.viget.com/extend/effectively-using-git-with-subversion/ for ideas with mixing up different SCMs.
I also want to +1 mxmissile for saying to take things slowly. I think you'll find it very difficult to introduce all these changes in one go. It's a lot to take in at first if you're not used to it. Try to pick the part you're weakest on, or will add the most value and build up from there.
Good luck!
One tool that got me hocked on TDD is TestDriven.Net which puts the test results in the Output window. I mapped this to the F8 key and the productivity gain is superb; write a test, press F8 and see this results in the output window.
One suggestion I also have to differentiate between having Unit Tests and doing TDD. I have found that TDD can be hard to push on to a team, while; unit, integration or functional tests are an easier sell. Having a bunch of tests that saves an hour going through a manual test day after day is a big win.
After a while people will start to appreciate some new ideas if it is helping them in their daily life. Then you'll be able to introduce a build server, and move away from SourceSafe.
In .NET environments, Microsoft Visual SourceSafe is most frequently used. (but it costs). Next to that you can opt for SVN or GIT. Git is more recent (and gaining popularity). It's easier to work with than SVN once you get it.
http://git.wiki.kernel.org/index.php/GitSvnComparison might help with your decision.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
We are currently using Fitness for subsystem testing.
we are having lot of issues using the tool, few to mention
Development time for writing Fixture is more then writing the actual code
Issues around check in of the dlls so that Qa can test them
Issues in running Fitnesse for project which uses NHibernate
limited help online
We are planning to use some other tool to do the testing
Few options which we know are
SOAP UI
Story teller
I am not sure whether we will have similar problems with these tools
It would be great to know if someone has experience using these tool and could guide us
In our project we have adopted TDD so we have Nuits for unit testing.
It would be great if anyone is aware of tools/ideas which could extend nunits for subsystem testing as well.
Component testing tools are all about calling functions. Your tests cause functions to be called in "fixtures" that then call into the SUT. Any tool based on this premise will encounter the problems you reference above.
However, most of those problem are manageable. For example you should not be writing lots of fixtures. If you are, something is wrong. Secondly, your fixtures ought to be little more than wiring code to call the APIs in your application. If your fixtures are doing significant work, then something is wrong.
In most FitNesse environments the number of fixtures is rather small. For example, there are over two hundred acceptance tests for fitnesse itself, but the number of fixtures in on the order of a dozen, and they are all relatively simple.
Get help on the fitnesse#yahoogroups.com site. The folks there are usually very responsive to questions.
If you can communicate with your software using text, then I have had success on past projects rolling my own framework using expect.
The framework I cooked up stored tests as XML files, using a simple xUnit style markup. The xml files were then transformed into executable tests using a stylesheet. I ended up transforming the tests into Tcl/Expect, but you could transform them into anything. In fact, if you wanted, you could transform them into multiple languages, depending on your needs.
Several people have kindly reminded me (in the same way you remind you poor dottering grandfather about the drool on his chin) that we are in the 21st century when they inquire why I would choose Tcl over some more modern language. As it turns out, for the purposes of this kind of testing, I haven't yet found a better choice. The Tcl language still kicks butt in this area. Trust me, I didn't wake up one day and say to myself "self, what I need a test framework implemented in a scripting language everyone will hate!"
Believe it or not, I really was looking for a tool, any tool, that had the following characteristics:
Cross platform. This was non-negotiable. We do a lot of cross platform development and we already use WAY too many tools that don't support cross platform development.
Simple syntax. Say what you want about Tcl, but the syntax is very regular. I knew that some native code would probably creep even into the XML files (and originally it was Tcl only, no XML) and I wanted the syntax to be comprehensible to a non-programmer. This simplicity is a core strength of Tcl. As it turns out, it also made transforming the XML easier too.
Free. My favorite price ;-)
Writing tests as simple xml files allowed non-programmers to write customer acceptance level tests - no programming required.
Easily extended.
I did not set out to home grow this to the extent I have. Initially, I looked at established test frameworks like DejaGnu and android. Mostly they had way too many features. They were so feature laden that I didn't think they would be easy for a project to start using without a lot of up front training. Looking at DejaGnu, got me interested in Tcl in general, and after a brief look at tcltest, I almost gave up. Both DejaGnu and tcltest assume you are an advanced Tcl scripter, which I didn't think anyone at my company ever would be. In addition, I wanted the test framework (if possible) to support an xUnit type of test framework and neither of these tools did.
Eventually I found TclTkUnit, a Tcl based testing framework that is designed along xUnit lines. It was only a short leap of logic to realize I could run TclTkUnit in Expect instead of tclsh and get everything I needed.
As it ended up getting used more, I added another stylesheet to render the xml files nicely in a web browser. The test framework generated it's own documentation.
On another project we needs a very basic sim / stim environment to emulate a person throwing switches and pushing buttons on a piece of hardware we didn't have. It only took a few hours to hack the test framework to function as a simulator. Creating the framework took some work, but we felt that it did pay benefits in the long run. I really believe that these types of unforseen consequences of creating your own tools is why people in the agile community & XP in particular have always been such strong advocates.
We have adopted a Fitnesse-based but practically-code-free approach using GenericFixture (google for Anubhava to find his wordpress site) for Fitnesse.
What this allows us to do is to create "executable test narratives" using a language that is friendly to the business-side (as opposed to the technical-side). This language, which is very easily defined, practically without coding, in Generic Fixture, is called a DSL (domain specific language). So we can write our test narratives using e.g. medical terms or even in a language other than English. Basically what we get is transforming our Use Cases into executable narratives.
We are starting to use it in a large project (15 ppl for 2 years) and it seems (so far) to have a good future.
It easily allows Test Driven Development or test-creation after development (traditional approach).
It is wiki-based (Fitnesse) and its versioning and refactoring funcitonality has proven so far sufficient.
I can give more info if anyone is interested.
best regards,
Aristotelis.
We use unit-testing frameworks like NUnit to drive our subsystem tests as well - the tests don't care how they are run. It doesn't have fitnesse's document-based approach, though.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
A few years ago I looked into using some build system that isnt Make, and tools like CMake and SCons seemed pretty primitive. I'd like to find out if the situation has improved. So, under the following criteria, what is currently the best build tool:
platform agnostic: should work on windows, linux, mac
language agnostic: should have built-in support for common things like building C/C++ and other static langs. I guess it doesn't need to support the full autotools suite.
extensible: I need to be able to write rules to generate files, like from restructuredText, latex, custom formats, etc. I dont really care what language I have to write the rules in, but I would prefer a real language rather than a DSL.
I would prefer to avoid writing any XML by hand, which I think for example ant requires.
Freely available (preferably open source)
The term "best" is slightly subjective, but I think answers can be rated objectively by the criteria above.
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
One is tup:
http://gittup.org/tup/
and the other is fabricate:
http://code.google.com/p/fabricate/
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
http://community.haskell.org/~ndm/shake/
Update: I haven't tried it, but this new "buildsome" tool also hooks into the filesystem, and was inspired by tup, so is relevant:
https://github.com/ElastiLotem/buildsome
CMake
CMake is an extensible, open-source
system that manages the build process
in an operating system and in a
compiler-independent manner.
Gradle seems to match all the criteria mentioned above.
It's a build system which took the best of Maven and Ant combined. To me, that's the best.
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
Final Builder is well known in Windows world
smooth build matches most of your requirements.
platform agnostic: yes, it's written in java
language agnostic: it doesn't support c/c++t yet, only java but it is extensible via plugins written in java so adding more compilers support is not a problem
extensible: yes, you can implement smooth function via java plugin, you can also create smooth function via defining it as expression built of other smooth functions.
I would prefer to avoid writing any XML: you won't see a single line of it in smooth build
Freely available: yes, Apache 2 license
disclosure: I'm the author of smooth build.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
What's the best way for me to learn how to use Subversion as a source code control for my Asp.Net Web Projects?
I haven't had much contact with source control before; however I have a very basic understanding of its features, so I'm looking for a way to learn the best practices.
Any tip will be very appreciated.
Once you've setup SVN you'll need to setup your repository structure. A common setup is to have a Branch, Tag, Trunk setup however there are others that may suit your needs.
Once you've setup your server you'll need a client. The most common one is TortoiseSVN. It doesn't integrate with Visual Studio, however it's extremely powerful.
Once you install tortoise, you'll want to setup your exclusion list to make sure you only commit files that are relevant to your project.
Then for a better understanding of how to use source control in general check out Eric Sinks Source Control HOWTO
TortoiseSVN?
Pretty easy to use...
It's integrated into the windows shell so basically it works from Windows Explorer.. I'm not sure if its integrated into VisualStudio 2008, but it's so easy to use anyway that I dont think you'd need it.. :)
EDIT: Plus, it's free.. :) And it's got a bunch of tools like Diff/Merge.. :) Although for that I think WinMerge is better.. But that's beside the point.. :)
I really recommend VisualSVN. It is a great product for integrating Subversion with Visual Studio.
http://www.visualsvn.com/
I would recommend ankhsvn for integrating with visual studio. I works nicely and looks similar to TFS. I also use tortoise svn for windows shell integration. Both complement each other nicely.
Not strictly related to Subversion, but Eric Sink has an excellent source control primer if you need to review the basics. Don't forget that the Subversion book is free, and it's probably the most complete (and yet still quite practical) resource on Subversion.
Like Web and Jerry, I generally like AnkhSvn for Visual Studio integration, and also make use of TortoiseSvn as a complementary tool. (For example, Tortoise's log viewer is still a bit more advanced, so sometimes I'll go in with that.)
That said, I'm not totally sure I would suggest using AnkhSvn for ASP.NET Web Site Projects. (I use it for ASP.NET Web Application Projects, Class Library Projects, and Console Applications.) There are some quirks that you might find frustrating. See this message in particular and this thread in general, from the AnkhSvn mailing list:
http://ankhsvn.open.collab.net/ds/viewMessage.do?dsForumId=582&dsMessageId=132185
You could probably live with the quirks, and maybe the AnkhSvn will eventually eliminate them all, but in my case I chose to move to Web Application Projects (instead of Web Site Projects) partly because they work better with AnkhSvn.
Also, if you do go with AnkhSvn, I suggest running one of the nightly builds, rather than the latest stable release; the nightly builds seem to have many fewer bugs and to be more useful.
I didnt get any answers when i was getting my first svn set-up for php development... so i would like to help you but i dont know any visual studio integration.
I used tortoise(btw is great and is for windows, i could help you im sure) and theres a couple of tutorials on how to set up a small repo in your own pc
Get familiar with source control terms and concepts first. Eric Sink has written a great guide for getting up to speed.
I know someone has already said "AnkhSVN", but I'd like to second that nomination. I use AnkhSVN for my department, and I love it. It integrates completely with VS2008, and gives me almost no trouble.
I also use TortiseSVN for its "Repo Browser" functionality... but I rarely ever have to go into that anymore.
Both are EXCELLENT solutions, and used jointly, should be all you need. And both are free.