Re: bugscan operations shut down

[Matt Hargett <matt () use net>]

nummish wrote:
> One thing I've been wondering about this weekend was your use of VS to 
> generate code for mono.
> I'm assuming you didn't have much in terms of UI (windows.forms vs some 
> other framework).. but
> did you run into many issues with autogenerated code (such as DataSet 
> code) running fine in the
> MS CLR, but throwing random or surprising errors on the mono CLR? Or did 
> you avoid using VS
> altogether for the mono code?

We would code/compile/unit test/debug/system test/debug in VS, then make 
sure the same code compiled and tests passed under mono. We do have a 
WinForms component, but that didn't compile/run under mono. (So far, no 
non-tutorial/sample WinForms program I have tried works in mono.) We 
didn't use DataSets, just XmlReaders and the like. There were/are 
problems we had to work around or wait for fixes, but nothing too hard 
to figure once you get into the mindset that weird problems may be in 
the CLR and not just your code ;>

We also just wrote code in plain vi on Linux and then did the reverse -- 
made sure it worked in .NET. There were never issues when going in that 
direction, just the other way. It is worth noting that test-driven 
development (unit-test first) is what made this go so smoothly -- 
detecting when there were mono CLR problems and tracking them down 
rather quickly. The mono irc channel was also very helpful some of the 
time :)

I learned at NAI and TurboLinux that you can't just use open-source 
without thinking about it (or paying someone like Redhat or Xandros to). 
This is the part that isn't "free". I monitored all the kernel and mono 
changelogs or bug/svn commit message mailing lists to keep an eye out 
for bug fixes and reports that might affect us. Keeping on top of things 
like this is why we had such success in the adoption of the platform, 
and kept us (and customers) from hitting major hidden icebergs most of 
the time.