System.Transactions is a new feature of the .NET Framework that will be included in Visual Studio 2005. Mike Clark shows how it provides a concise set of objects and interfaces for working with transactions as well as some interesting performance optimizations.
Introducing System.Transactions in .NET Framework 2.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…anyone have the ETA on .NET Framework 2.0 (final)?
Q3 2005 for .NET 2.0
Q2 2006 for Mono 2.0
🙂
but I have to admit that .NET 2.0 looks very good! And C# as a language is very nice.
Just my opinion and 2 cents.
While I prefer .NET over Mono (mostly because of IDE and MS tools which lack on Mono), and while, as Anonymous said, Mono 2.0 is dued to be released almost a year later .NET 2.0, also consider that present Mono implementation already has a few features which are going to be released with .NET 2.0, like Generics, for example.
Surprisingly, Mono VB.NET compiler is still far from being a production-ready toy… (another proof of a bad development behaviour in OSS… “let’s do what we like most”…)
See the Mono website, look at the Blogs – they’re rewriting the VB.NET compiler starting from the Mono C# compiler …
Sure, I checked that. I can code C# but I prefer using VB.NET so I check it from time to time.
I was surprised because I was expecting them to consider Vb.NET compiler a top priority like C#. After all, we know that MS used VB to let many people start coding and I thought it was wise to expect that Ximian-Novell could use same way to attract users / programmers.
After all, that’s one of most interesting .NET features. I will monitor that but VB.NET compiler is still far far far away 😉
A nice mix would be MONO + OpenSolaris… I’m curios about it…
Q2 2006 for Mono 2.0
Based on past experience of when Mono 1.0 was delievered (and it shouldn’t have been a 1.0 release) that’s pretty optimistic.
I was surprised because I was expecting them to consider Vb.NET compiler a top priority like C#. After all, we know that MS used VB to let many people start coding and I thought it was wise to expect that Ximian-Novell could use same way to attract users / programmers.
VB.NET will likely never get the same priority as C#, for two reasons:
1. VB.NET isn’t a standard, and Microsoft can change it any way it wants at any time. Having a C# standard to base the implementation on simplifies the construction of a C# standard.
2. Mono’s class libraries are in C#, not VB.NET. Thus, a C# compiler is a necessity. VB.NET isn’t, at least until the VB.NET runtime library is re-written in VB.NET…
There’s also less of a need for a VB.NET compiler, as you can always compile your VB.NET code under VS.NET and execute under Mono…
[i]Surprisingly, Mono VB.NET compiler is still far from being a production-ready toy[i]
IMHO the basic.net (and any basic variant) language is far from production-ready. But C# rulez.
1. VB.NET isn’t a standard, and Microsoft can change it any way it wants at any time. Having a C# standard to base the implementation on simplifies the construction of a C# standard.
I’m not discussing the importance of C#, of course. However, it is unlikely that VB.NET will change so much not to allow MONO team to follow changes. After all, main target is .NET compatibility, not a life of their own. At least until MONO will aim to .NET compatibility and not viceversa.
2. Mono’s class libraries are in C#, not VB.NET. Thus, a C# compiler is a necessity. VB.NET isn’t, at least until the VB.NET runtime library is re-written in VB.NET…
Again, I perfectly know that C# was needed. Infacts, I’m saying that MONO is still half a toy, not that is unusable. However, if one of most interesting feature of a platform is to be language neutral, it doesn’t look clever to think about VB.NET like something you will do when you have some spare time… 😉 I would understand (but I wouldn’t agree) if they had put on a side JScript.net or J# but Visual Basic has been part of MS success. It looks clever to learn from mistakes and from successfull strategies.
There’s also less of a need for a VB.NET compiler, as you can always compile your VB.NET code under VS.NET and execute under Mono…
Then I would stick with Windows.
Again, I’m a bit disappointed about this project not because it’s not good or can have a good impact but because it’s being developed in a very weird way.
I could have understood that when it was Ximian alone but now that Novell got involved I’m a bit lost. Developing such a framework without any decent IDEs doesn’t look very clever, expecially when a platform has been developed to “do more in less time”. As MS showed, tools are not “tools” only but an important part of your strategy. Infact, they’re not releasing .NET 2.0 BETAs alone but they’re also providing a full set of (BETAs) tools to fully experience the framework. One should also notice that latest MS BETAs are all in all almost production ready, meaning that you can already use (though this is not recommended) .NET 2.0, SQL Server 2005, Visual Developer Express and so on. Right now I can’t even think to test some of my code on MONO.
Stripping important parts of the framework doesn’t look very wise too. Right now, if a Unix user liked MONO, he/she will simply find more useful to switch to Windows…
And I’m speaking as someone who’s REALLY interested in MONO. Actually, right now mostly .NET, Windows Media and a few other reasons are keeping me and my company stick to MS technology…
Regarding Mono 2.0, most of what people are looking forward to in .NET 2.0 will actually be available in Mono 1.2: http://www.mono-project.com/about/mono-roadmap.html
Managed Windows.Forms has been coming along nicely for mono recently – look for the 1.1.4 release soon (source is available now).
…regarding the info on the ETA (of both). But we all know M$, they usually don’t deliver on time (*cough*SP2*cough*). 😉