Develop Reference

GitHub Continues Integration C# Windows

I'm just starting my Exam project at my school. Studying Systems Development with C#.
We're using GitHub as our online repository, and it just recommended to set up "Continues Integration". I looked at it, and the idea seemed nice. Our course is based around Test Driven Development, so we already have tests in place.
I first looked at Travis, unfortunatly, I cannot figure out how to get this to work with Windows, nor Unit Tests.
Question is, is there a tool we can use to acheive continues integration with C# for windows platforms, for free?

It is "continuous" integration, and yes, it is a good idea to learn about it.
Unfortunately, the question is too broad to answer directly. There are many solutions to get a working CI running, both locally and in the cloud; both for free and not-so-free.
It is, for a hobby/uni project, also perfectly possible to roll your own, with a few cron jobs or commit hooks.
CI simply means that your test/build scripts are running automatically, ideally after each commit and for each separate branch, so you get early warning for bugs creeping in. The more expensive or complex systems just add a loaf of customizability, reports, history, notifications etc. on top.
I would suggest googling a bit more. You really should be able to find something including documentation on how to use it. Wikipedia should have a handy table which you can filter down on "free" and "windows".

Iphone Apps using C#/Mono

There are various questions (mainly around 2009 to early 2010) discussing use of the Mono framework to write apps in C# and deploy them to iPhone. Also there is some discussion of the Unity Framework, but I'm more interested in a fairly standard UI app.
Has anyone successfully developed and released a commercial quality app using C#/Mono? If so, what were the lessons learnt? Pain points? If you know of other people who have done so, how have they fared?
Thanks!
Mark

The basic answer is yes, there are a lot of applications out there that have been developed using MonoTouch. You can find some nice numbers on Novell's site but there are a ton of games and other application is the AppStore that were developed using MonoTouch.
I would start your investigation by going to review articles that walk through the good and bad of MonoTouch. For example, here is a good starting place:
http://www.bryanthankins.com/techblog/2010/01/17/monotouch-review-porting-an-obj-c-app/
http://www.devproconnections.com/article/mobile-development/review-monotouch-enterprise
Then I would look through some tutorials to see how exactly this is done so you can see if it will fit in your environment. There are a lot out there that show off how to use MonoTouch, including these:
http://vimeo.com/6689472
http://blog.keen-edge.com/category/monotouch/
Finally, I would look at what is happening currently with Attachmate and the takeover of Novell. There are some real issues there that may cause you to reconsider going with MonoTouch. For example, while Mono's future may be unclear at Attachmate, it seems that it might be continued through another company:
http://ostatic.com/blog/mono-continues-without-novell-attachmate
This uncertainty might not be what you want in a project you are counting on so you need to work through that before committing.

Windows Mobile is hell for new developers? (If I'm not wrong)

I am new here and new to windows mobile development. But I have seen and experienced, for new developers having no trainers or experienced people around windows mobile development is like a hell shaking one. In complex topics you are going to find help from nowhere except you are lucky.
So my question is how should I gain expertise in windows mobile without having any trainer. The thing that i only know is C# and have a rough experience of one and a half months in windows mobile development

Yea.... it's quite a step to be honest. It's evil as well because at first glance it looks to be so very simple but then it turns around and bites you.
I speak from experience as I made this journey starting in 2003. Oh, I had no trainer either so I just learnt via bitter experience.
Know your limitations
I remember the first ever CF application. I was such an idiot..... I wasn't much good at developing back then either. First mistake I made was overestimating CF 1.0. I couldn't possibly imagine that the CF didn't have a read-write datagrid so I specced it...... then found out that oh yes, there wasn't one. So I had to write one myself (and remember I was rubbish at this time too). I hacked one into the existing datagrid (although tbh I should have just started from scratch). I remember that the "delete" function where I had to remove a row and then select the "now currently selected row" was hellish because it would go up or down depending on how many items were in the collection and where the scrollbar was.
There are many times that my desktop development buddies will categorise me as mad when I tell them what i'm working on.
"You're doing manual Xml Parsing? Are you crazy?"
"Ewwww code gen?"
"You.... re-use your windows forms?"
Yes, working on CF will make you look crazy to outsiders.
Performance
This can be taken to extremes but every little does help. If your building a big flexible application then think very carefully about perf. Consider replacing Reflection with codegen. Consider using an XmlReader instead of an XmlDocument. Sure this advice might be crazy in most cases for desktop but for CF it is sensible.
Know your PInvokes
In desktop land you can live in pure managed. No chance of that happening on CF. Some of the simplest things (playing a sound, setting the time, changing the volume, networking, etc etc) still only exist in the unmanaged world in Mobile. OpenNETCF have done an awesome job in exposing some of these but you will always stumble into one or two where you will need to write your own.
There is true, there is false but there is also FILE-NOT-FOUND
PowerManagement, how I love thee. In a usual C# app code goes the way of the logic (like a fork with an IF), perhaps an exception will be thrown and perhaps there will be many threads treading the path of the code. This is already complex. Add into the mix the idea that the power might vanish at any point. That's right, the using statement you were relying on to call Dispose might never call dispose because the device was turned off and then it ran out of power.
Device specific fun
Another big difference in desktop/mobile world is hardware and manufacturers. On the PC you can generally assume that the hardware will be okay and firmware updates should do the job. In CF a firmware update may well kill your code. Some hardware might sorta, kinda work if you bash it round the head in a certain way. Basically your device integration can (worst case) be a big black hole of time. Remember to work this into your estimates.

Learning to write actual maintainable, saleable and usable applications for the Compact Framework is difficult. The CF is way, way scaled down, so there is a lot that a desktop developer will not have that they are used to. I'd been developing CF applications since before the CF existed and I still find many things difficult (just try getting a control with transparency drawn into a container on a form with a background image and doing it without looking at the code in Project Resistance).
In my opinion, there really are 2 things that are essential.
You must be able to read and understand C/C++. All of the SDK docs are in C and a large amount of samples for using anything useful on the device tend to be in native code. If you can't translate that, you're at a serious disadvantage and you have to hope someone else has already done the work. Even if they have, they you have to rely on them having done it right.
You need CF experience. Desktop experience is largely worthless in the CF environment once you get past syntax. Laziness like data binding, using Data Sets, not cleaning up objects and all of those things that desktop developers do every day will kill a CF app. You need to throw out what you think you know and start re-learning. You do that by simply writing code every day.
Don't expect miracles either. I've been writing code for Windows CE for over a decade now and the amount of things I don't know about the platform still far outweighs the things that I do know.

If I understand your question....
If you have c# experience, you will not really need a trainer.
Building on Windows Mobile is very straight forward and easy if you know .net.
If you have Visual Studio (I think any edition apart from express), it is simply a matter of starting a new project and selecting mobile device.
I honestly love it! I build small applications all the time for my phone... little calculators for when I go shopping, programs that fire off a trigger and get a response from a web service and more... basically to make my phone do what I want (and no one else would be interested in).
I go by the method of simply writing an application the way I want and then if a feature is not supported by the cut down .net compact framework, I try and search for an alternative method that is - however, I have found little that doesn't work.

Developing in the CF can be challenging. Knowing C# is important before moving forward with the Compact Framework - to which you have. I would suggest that you start with smaller applications. Once you get the feel of Visual Studio and working with the emulator, I would suggest that you play around with a setup project. Once you get an idea on the flow of CF development, deployment will probably be your next step.
One area that I find that I spend time on is Designer support. If you are writing controls for other developers - design time support is crucial. Checkout the article at http://www.mooseworkssoftware.com/VS2005%20Control.htm for more information (I know its for VS2005, but it really helped our development).
As you move forward, create small projects in different areas and learn the pitfalls to each. An example would be GUI and dealing with different screen resolutions that are supported by different devices. Next, maybe DB support. After you get comfortable with a couple of areas, bring them together in a project and build from there.
Give it time - sometimes it will be painful, but the possiblities are endless in writing applications for the CF and what the market is calling for.
Craig

To answer your question, Windows Mobile is like paradise for new developers. You use the same tools and languages you are used to from the desktop world and essential things like in device debugging and emulators are just there for you. You can build simple applications with no training, just by following one of the many beginners tutorials available.
After that, there are of course many complicated and difficult issues to overcome, but in my opinion the fact that you will be able to start quickly is very important.
Also, you need to also need to compare Windows Mobile with other mobile platforms. Compared to platforms like Symbian, Brew and J2ME Windows Mobile is much more advantageous for new developers. I don't have experience with iPhone and can't comment about it, but comparing to everything else, Windows Mobile is easier.

Starting a new Site - Should I "Use a Template" or "Write from Scratch"

I have been thinking of starting a site of my own for long time. I am good at all concepts of C#/ASP.NET and all DB stuff. I have created and can create a site from scratch for myself. But the effort/time involved in creating a site from scratch is little discouraging, where next thing (and more important thing) I need to worry about is the content on the site.
I have seen many sites and blogs (few links below).
I need to know, what is the general approach while creating a similar site?
Are there any general tips i need to be aware of before starting one?
http://naspinski.net
http://codeclimber.net.nz

Do you mean stating you own Blog?
you can open blog on some free service as Blogger and see how it goes.
Later you can buy you own domain name and hosting, install existing Blog engine there(even open source if you want to tweak it) and continue from there.
after comment clarification:
Buy a domain name, buy disk space and traffic from hosting company. Install ant cms(content managment system)/blog/forum/anything else you wan ton the host. Develop only the parts you can't find in existing cms/blog systems. No need to develop everything from scratch. With saved time you can take any open-source blog/cms engine and help them with patches.

Consider some open source C#/asp.net blogging platforms:
Oxite
BlogEngine.NET
Subtext

If you're talking about a blog site, there's no need to reinvent the wheel unless you just want to. There are plenty of capable blog engines in any language of your choice. Go with one and extend it if necessary.

Building your own blog engine is fast and easy. Building a good one is slow and hard. I've written many iterations of my blog - currently version 6 using ASP.NET and C#, and working on the design for version 7.
As to whether it's worth it, that's really your call. Do you code in your free time? Enjoy it? Are you willing to go through the whole lifecycle?
You will be responsible for:
Analysis & Design
Development
Testing
Deployment
Prod support
It's worth it to me. Is it worth it to you?

It really depends how much time you're willing to spend on it and what kind of site.If you want a blog site,there are a lot of free blog engine out there that you can use and takes a little time to make it live.My number one recommendation is blogengine.net...very flexible,a lot of choices for theme,and easy to set up.However, if you're like me that is willing to spend a lot of time building it then go for it.I started building my site....a social networking site(http://www.joecaps.com) December 2008 and until now I'm still building it.

Migrating a project from C# to Java

With some changes in the staffing at the office, the levels of C# expertise has dropped off precipitously and there are now more Java developers. It has gotten to the point where the higher-ups are considering moving an existing .NET project written in C# into the Java world.
Aside from the obvious problem of starting completely from scratch what are the possible ways that this company can accomplish a successful move of development on a project from .NET C# into Java?

Here are things to consider:
Is this big project? If Yes, try to stick with C#
Is this medium sized project with components? If No, try to stick with C#
Is this small project meant to be deployed on windows only? If yes, try to stick with C#
Is this old source code? If Yes, try to stick with C#
Do you use windows OS specific APIs? If Yes, try to stick with C#
Do you use any third party APIs without Java counterpart? If Yes, try to stick with C#
Do you use .Net in "deep"(data binding, User controls etc.)? If yes, try to stick with C#
Migration time is more acceptable than getting new/converted C# guys? If no, try to stick with C#
Do you think end users will not be receptive of changes, if you are to use Java framework which will change presentation? If yes, try to stick with C#
Check commercials
If you decide to convert:
Go per component
Go per layer
Have lots of tests
Check if there are tools to help (however small help may be) with migration

Just to add to Brian and Eric's opinions, I would say that picking up C# for a Java developer should be straightforward in my opinion. They are conceptually very similar languages and I would suggest training your Java developers to gain some C# skills so you won't be forced to go to the hassle of a migration process.

I subscribe to Joel's view that a total rewrite is almost always a mistake. Other posters are right: C# and Java are similar enough that any competent Java developer should be able to become competent in C# in a matter of weeks or months. That's not to say they will be experts. That takes longer but as long as you have some C# developers who can guide the process then you should be OK.
It's hard to comment on whether or not such a transition is a good or bad idea without knowing specifics of your application: size, type of application, industry and so on.
I would be extremely reticent about such a switch because, in my humble opinion, C# is now a much more modern language than Java and I say this to you as someone who has been a Java developer ofr over a decade (since the 1.0.2/1.1 days).
That's not to say that Java is bad. It's not. Sun does have a cloud hanging over it and demonstrated an unwillingness or inability to drive the platform forward in recent years.

Regardless of the languages involved, the management of this company sounds insane. For anything other than a trivial application, how can it be economically sensible to rewrite an entire code base from scratch instead of just hiring a single person with some skills in the right language? Is this a business with that well-known problem: too much spare cash?!
How long has the existing code been in development? If it's barely started, I could understand this. If it's seen a release and has active users, it will never make sense to throw it away. If you donated the C# code to a start-up with the right skills, think how much of a head start they would have over you.

Before you finish converting the .NET project into Java, all those Java developers who were part of the conversion project will have learned C#. So then you don't anymore need to convert it to Java (and you can throw away all Java code which was produced in the conversion), because now you have a development team which can do both Java and C#. Problem solved. :D

Have a look at Net2Java, which puports to assist in converting your code from C# to Java. I doubt it'll be perfect, but its one way to remove a lot of drudgery from the task, leaving you with the kinks of incompatible framework calls and language features to iron out.
Once you've done that, your task is like any other large migration project - test, test and test again. Unit tests, System integration tests, then end-user tests. You should havew those tests already in place that you used with the original application, apart from the unit tests, they will still be relevant.

If there are any components that are already isolated or any of it uses a service-oriented architecture, you could conceivably migrate one component at a time (where each individual component is a rewrite) and still have the components talk to one another using the same interoperable network protocols. Probably depends on what type of app we're talking about.

Make sure you have tons of tests, because such a migration will bite you where you expect it least.

Do you have more .Net or more Java applications in production. If your already have a substantial investment in .Net servers and applications, why not ask for volunteers among the Java developers to move to .Net? The language and syntax is very similar, so the hard part would be learning the framework and unless they would spend all their time doing UI development even learning the framework is not that hard.
In our office we have a number of very good developers who move back and forth between Java and .Net as needed.

I am not a Java expert, but from my experience working with Java code whilst being a C# fan, the following are some of the possible headaches:
Generics are implemented differently in Java and C#.
Boxing/Unboxing behaviors are different between Java and C#
Java class naming convention + lots C# generated code
String handling (i.e. Unicode/ASCII concerns) can be problematic depending on the quality of Java/C# code being ported over.
Personally, I don't think writing from scratch is a bad idea at all. Since you already have a working architecture.

In order to prove to management, you always needs to talk in terms of ROI and numbers. Show them that if you move these applications, it will take tremendous amount of time, QA resources, and can easily take a back seat if it gets de-prioritized due to some other project or new development taking importance.
I had success when I showed them the timelines, ROI, work involved, money involved, etc.
So now coming to the actual point, I do think Java developers would be able to support C# unless they have some fundamental mental block against Microsoft technolgies.

Possibly you could use jni4net - opensource bridge ?
Or list of other options I know.

I'm somewhat surprised noone even suggested the idea of rejecting migration.
I do not believe a C# developer can be forced to switch to Java (or vice versa) because he was told to (well, if he's threatened with a gun then maybe). I takes much time, exercise and passion to master at least one technology stack. You just can't start overnight with a new technology and expect to provide the same quality.
I'd personally not bother until told to start migration. At which point I'd tell the manager that I'm .NET guy and won't switch to another technology just because they decided to.
As for the technical side, it's not the language syntax that differs but rather libraries and their features. Of course, if all the latest bells and whistles of .NET 3.5 have been extensively in use then the language difference will provide you with a real challenge.
That's certainly a funny way, just decide to migrate applications from .NET to Java. Someone has no idea of the hassle involved...

I realize that this is an old question but to anyone else going down this path, you could try this open source C# to Java Converter:
http://www.cs2j.com/