Submitted by Specialized programming languages and their supporting environments have always been tightly coupled: SQL and the database; business rules and the rules engine. It’s tempting to wish for an überlanguage or one syntax to rule them all, but what really matters is a common environment. At its 2005 Professional Developers Conference, Microsoft showed that it’s finally putting all of its eggs into the .Net basket.
Finally looks like things are going forward in the world of .NET. Should see some great products arise from .NET 2.0.
Maybe / Maybe Not
Our company supports two very large .NET applications and we have major problems with both. The problems are not with the code or the applications, but more with how .NET is integrated into the operating system.
Security Patches: One of our biggest problems are microsofts own security fixes. Very often Microsoft security fixes require code changes in .NET, or the code breaks. They are consistantly change which objects you should be using, or how you are able to use them. Most of our customers apply Microsoft security fixes when they come out, but many times this breaks the applications. This causes major support issues for us and affects our customer relations.
Permissions: The fact that .NET permissions are so tightly integrated into the operating system should be a really good idea, and sounds great on paper. This super tight integration causes never ending problems for really large applications. If the permissions are two loose then you have security problem, too tight and the app breaks in hard to track down ways. The other hard part is that the permissions have to be applied in so many places (IIS, registry, file system, processes, etc…)
These two applications are very large financial applications with thousands of ASPX file and hundreds of TLB files. I’m not complaining that .NET is too complex, just that IMO the app is too integrated into the operating system.
I can understand that. I have never been lucky enough to be on a large scale project. I mostly do business sites that get peoples name out and basic shopping and pickup in store type things.
That’s a very interesting opinion from someone using .NET in real world apps… and a very big app! For people like me who get involved in .NET development, that’s very interesting.
A few comments:
Security fixes and applications
I’m mostly involved into Web development and I rarely experience such problems, though sometimes that happens but very rarely in my experience. I tend to believe that your application uses unmanaged code too and probably much of it (COM? COM+?).
Security and permissions
I agree: that’s one of hardest parts but, IMO, the thightly integrated permission system allows a great flexibility and let .NET application use the HUGE Windows capabilities in a very streamlined way.
A few days ago I saw a small example of a .NET Web app using Windows Media and SAPI to convert text into spoken audio and save it as WAV or MP3 to play it over the Web. That was amazing and required no more than 30-40 lines of code. Amazing!
However, the other face of such coin is that you need to secure almost the whole OS to achieve a good level of security. This isn’t very hard on a single server, but can be terrific if you write an application which needs to be installed on (say) 100 client PCs.
IMO, Microsoft should provide a way to group system functionalities and apply super-permissions like: “Should WEB app have access to media services?” If no, ANY access is automagically disabled. That would be better than browsing the whole system directory for DLLs and remove permissions to them or playing with hundreds of objects in component services. Then you should be able to set exclusions like user XYZ can have access to encoding but cannot start WMP and so on.
However, very interesting post (which proves that .NET is being considered for large enterprise projects). Thank you.
“I’m mostly involved into Web development and I rarely experience such problems, though sometimes that happens but very rarely in my experience. I tend to believe that your application uses unmanaged code too and probably much of it (COM? COM+?).”
For the most part your right, but no always. Just two month ago we were hit with a major change in the way the XML soap object is used (from a security point of view). We had to do an ASAP rewrite to a lot of code. Two customers said they didn’t think we reacted quick enough and were quite pissed, but the bottom line is that we had no idea the change was coming until it was released. This is just one example of course but many other time Manged objects have changed because of security isues, or worse microsoft changes the requirements for using them. Maybe you don’t need to change the code, but change the way you are securing the app, and many times those changes conflict with the way the user is used to using the app.
2nd answer is yes, we do use a good amount of unmanged code, but many times we have no choice. We stay away from it as much as possible, but many API are still only accessible as unmanged API’s. Maybe 2.0 will help us out with this?? I have not looked at 2.0 yet.
The other problem with the permissions that I didn’t mention before is that many different aspects of .NET require you to understand permissions in different ways (for different subsystems). When you have a large group of developer, and then you start expirencing turnover (which happens to everyone), then keeping track of all these little tweeks becomes really hard. And keeping the Support/implementation people in-sync with the developer on all these permissions issues is really hard.
Just try to find someone that is good at setting up a security internet hardened windows machine, that also understands the hundreds of permission tweeks that are required to get your app running. Those people are far more rare then you would think!!!!
Many times our implementors end not being able to get all aspects of the app running, or end up opening up too much of the OS.
I like .NET. I’m not bashing .NET I just worry that some of the ideas built into .NET make it wonderful and very fustrating at the same time.
2nd answer is yes, we do use a good amount of unmanged code, but many times we have no choice. We stay away from it as much as possible, but many API are still only accessible as unmanged API’s. Maybe 2.0 will help us out with this?? I have not looked at 2.0 yet.
.NET 2.0 will extend the whole framework and provide additional features (and performance… just looked at a WebService benchmark from MS and it’s a very good improvement), however I would say that such problems won’t be ironed out until Vista (and Vista Server). It’s a fact that users need to run software as admin to be able to exploit the whole system functionalities and that makes securing a box very hard (the more you secure, the less you can do).
However, they did improvements on the security side as well. For example, you don’t need to run web application as full-trust apps anymore to achieve good results. They fixed their ADO.NET SQL Provider in order to let apps running at medium-trust level connect to SQL DBs and that’s big improvement. Plus, the whole security policy is highly configurable (you can run applications at medium-trust level, for example, but let them access registry and so on…).
Vista will hopefully sort that out by providing enhancements to that model. However, .NET 2.0 is a very good new version though it won’t change things dramatically. I’d say that it will tune things up in order to achieve more performance, more stability. Since it should be fairly compatible with 1.1, I’d give that a look.
And keeping the Support/implementation people in-sync with the developer on all these permissions issues is really hard.
Just try to find someone that is good at setting up a security internet hardened windows machine, that also understands the hundreds of permission tweeks that are required to get your app running. Those people are far more rare then you would think!!!!
I can really trust you on that! Securing a Windows box while keeping most features up and running isn’t very easy. And then you have to let those information flow from people to people, from devs to support… and hard task indeed for such a big application!
I like .NET. I’m not bashing .NET I just worry that some of the ideas built into .NET make it wonderful and very fustrating at the same time.
Yeah, .NET has to mature a little bit. After all, it’s been out relatively short if compared to other technologies and must tune to match tighter requirements like security (which became an huge problem since when .NET was planned in 1999 or 2000…).
Thanks for the information
It sounds like they are moving .NET in the right directions, and I agree that a little more maturing will help a lot. I think that 2008 is going to be .NET big year.
I’m very happy to hear that work has gone into the ADO.NET SQL libraries with respect to how the security is implemented.
I’m looking forward to trying 2.0 out. It took us a year to move from 1.0 to 1.1. Part of that was because we were extending the product at the same time, but I’m asuming that our 2.0 conversion will be just as lengthy…
No problem 😉
I’m looking forward to trying 2.0 out. It took us a year to move from 1.0 to 1.1. Part of that was because we were extending the product at the same time, but I’m asuming that our 2.0 conversion will be just as lengthy…
Actually, if you have to start conversion yet, I would suggest to skip .NET 2.0. Let me explain that.
.NET 2.0 is good, very good, as I said. However, it includes a few technologies which are final, like WinForms. We already know that future of .NET will be Indigo and Avalon (WPF) which will be out in 2006 (that is, a few months from now… an year max) but we already have BETAs since they will backported to XP and Win2003. It might be wise to develop on such technologies which represents the future of .NET (and Windows).
However, if you’re interested in Linux/Unix market, you might wish to use .NET 2.0 whose features will probably be implemented in MONO, or at least most of them (like Generics).
i’ve seen a little bit of that in my own dabbling w/ a side project desktop app i made and gave out to different ppl to test. i’ve got admin access, and when superusers run it they get sooo many unexpected security gripes that i lost the time to track down all the bugs. so it languishes, not even on the back burner, but in the freezer. i wouldn’t even consider .net for some desktop app to deploy, unless it was only going to be used by a handful of ppl in the same ou. what you’re dealing w/ security fixes breaking the application sounds completely unacceptable. what a mercurial, nightmarish platform.
Whilst it sounds encouraging in general, I nevertheless am really sceptical that this is a good idea. The problem is you have to cater for the lowest common denominator in SQL so you wont be able to use propriety or more advanced sql commands (or their equivalent in Linq).
So other than simple data access its not really that useful. (at least it wont replace ADO)
It will probably include all the more advanced features of the SQL Server Transact-SQL dialect, but leave the other databases out to dry. 🙂
I understand the motivation behind this, and partly agree with it. Enterprise developers are required to know way too many different languages. With .NET you need to know at least some or most of the .NET languages (because you will eventually run into code that was written in other languages that you have to intergrate or modify). You need to know all the dialects of the database servers you are using, and all their crazy quirks. Then you need to know all the web languages – HTML, CSS, XHTML, XML, Javascript. You have to have a proficiency in so much just to do basic stuff.
This is the same for J2EE developers – except we get to enjoy extra fun things like EJBQL. 🙂 Anyway, in an ideal world, this would be great (and other people have mentioned how similar things are implemented in pyhton, etc). However, I think that this model will run into problems when people want to start doing some database performance tuning and data access tuning. People will start off using these new features, and then where their data access gets too complicated or slow, they’ll re-implement it with custom-written queries and custom scaffolding.
The really neat thing that I think Linq will do well is that it works on a number of stores – not just database access. XML files will also be supported initially, and I can see people writing providers for a bunch of things. So for trivial data storage, this will let developers swap stores much more easily and their code should be much more flexible.
When all of their shipping software, especially Office, is written in .NET I’ll start to be impressed, until then why should we use it when they won’t eat their own dog food?
Damien
I would say that the Microsoft.com website is a pretty good example of MS eating their own dogfood (most of it has been rewritten in asp.net). Also, most of the internal LOB apps over at MS are written in .Net at this point (they were starting the transition when I worked there 4 years ago, and from what I’ve heard 100% of the LOB web based apps are now asp.net).
Office would be an extremely poor candidate for a .Net rewrite…MS has a 20+ year investment in the codebase, and it’s reached a very stable state. In future versions they may start incorporating some .Net GUI widgets in the suite and just wrap those around the legacy COM components (similar to VS.Net and some of the Vista GUI), but the underlying codebase isn’t going anywhere anytime soon.
You don’t need to rewrite the application, just provide .Net interface. It similar as with GNOME. Even if it’s written with C you can write GNOME applications with Python, Ruby, Java, C# etc. because there is interface for each of them. You can do same for all MS apps by providing .Net interface.
There is already a .NET interface for Office. It’s done via interop. You can access the object model via .NET, see Visual Studio Tools for Office or even “Monad”.
“Monad” example for Excel:
#Create Excel application instance
$e = new-object -ComObject Excel.Application
#Get properties and methods of the Excel object
$e | get-member
Addins can even be made using .NET (see MSN Desktop search Outlook integration).
You want to be impressed? You want to see Microsoft write 100% .NET code? On Channel 9, you can see a video of an interview with the Hotmail-team: they’re rewriting the entire Hotmail-application in .NET (using C# language). Hotmail is one of the largest web applications with most traffic. Doesn’t that show confidence? Doesn’t that prove that Microsoft trusts .NET?
http://channel9.msdn.com/Showpost.aspx?postid=118322
At the risk of being a troll, MS moving Hotmail to NT from BSD also proved MS trusted their own tech, but of course we all remember that it couldn’t cope when they first attempted it. All users of hotmail must be crossing their fingers and hope the .NET rewrite isn’t a similar miserable failure.
Never mind that the process wasn’t just moving the same code to NT from BSD and actually involved large changes in software and hardware setup to gain perf and reduce cost.
http://outlook.microsoft.com/technet/interopmigration/case/hotmail/…
The video clearly shows that they are already testing it with a few 1000 users. They also tell us that there already have been some problems, but they’re working closely together with the .NET team(s). Because of this close cooperation, .NET can be improved a lot faster.
So, they should REWRITE Office in .NET so that you’re satisfied? Now, that’s the stupidest thing ever.
Huge applications like Office do not get rewritten “just because”. Office will soon reach version 12: most of the bugs are found & fixed, app itself is polished — why the fuck would you want to start from 0? Just because you say so? So that they can impress you?
On the other hand, take a look at number of **NEW** inhouse, business, applications: .NET is definitely a technology of choice for many, many applications. I emphasize, *NEW* applications. No one sane is going to rewrite (huge) applications just because .NET is the latest technology from MS (or any other vendor).
Dude, get real.
Of course .net has lots of bugs and keeps changing. Using a non-native instruction set for serious system applications is a new step (modulo FX!32). I have to say I think it is a quite good idea. Of course this doesn’t mean I have to like the rest of windows or believe that MS should instantly move all it’s applications to this technology. However, I think using a OO language to do system control rather than ascii is an advance which has been needed for a long time.
Of course I’m somewhat more skeptical about integrating this idea into windows. This sort of change seems more appropriate to rebuilding the OS from the ground up and dealing with .net technology (and other JIT/interpreted languages) in a first class manner. Most importantly changing the controlling programming metaphors to a different metaphor which expects everyone to play nicely with .net objects. Still more props to them if they can pull it off in windows without disrupting their application base.
. . . when i see that mono gets barred
http://tirania.org/blog/archive/2005/Sep-06.html
from certain .net events. i thought c# was going to be huge, but now i’m wondering abt how viable it is really going to be for cross-platform stuff if ms does what ppl have been fearing all along i.e. block out interoperability stuff like mono/dotgnu. makes me wonder, ‘why not just stick w/ java?’
when i see that mono gets barred from certain .net events. i thought c# was going to be huge, but now i’m wondering abt how viable it is really going to be for cross-platform stuff if ms does what ppl have been fearing all along i.e. block out interoperability stuff like mono/dotgnu.
I don’t remember any case where Microsoft “blocked out interoperability stuff”. Mono is doing it’s thing, Microsoft doesn’t have to be involved.
As for the event your talking about, this is a private company event. They have the freedom to invite/bar whoever they want to. I’m not sure Microsoft would be welcomed in a Linux event. Not including Mono in their day to day business doesn’t means they are fighting against them. At least I don’t recall any attack, maybe I missed something.
One tool to rule them all,
One tool to find them.
One tool to bring them all,
And in Redmond, bind them.
In the land of Washington where MicroSoft lies.
Reminds me of the Java world, and SQLJ. LINQ is really a precompiler to map to an underlying library, just like SQLJ was a precompiler to map to JDBC.
It wasn’t a good idea then, and the Java world moved to more powerful and flexible persistance frameworks like Hibernate. LINQ looks more powerful, but it’ll be interesting to see if it’s just window dressing on a more fundimental problem, or really expands the language utility.
It’s not just for database access: LINQ allows you to query databases, XML files and .NET objects (every object that implements the IEnumerable interface) using the same code.
Here’s an example:
var x =
from u in Users
where c.Age >= 18
order by c.Age
select c.Name;
In this example, Users can be a database table, an XML element, a List of users, an array of users, …
I really hope that people won’t use the database stuff in a real world application. Moving things like sorts away from the DBMS is a very, very bad thing, performancewise…
Being able to use this for other things such as arrays and XML documents are good, but don’t touch the databases. They do these things best themselves.
Keep these operations on the good-performing hardware where your DBMS is located, not on a crappy client.
Huh? Moving things like sorts away from the database is actually a very good thing (unless the column has a clustered index on it). Would you rather have 1000 concurrent clients doing a large sort on a server, or 1000 concurrent users sorting a set of data locally?
In this case the clients with good performing hardware will benefit and clients with old hardware will suffer alot. Is this a step forward?? Not really. 1000 sorts by a 1000 persons isn’t that much in a large scale application. Databases have highly optimized code to do this. Might depend on what databases we’re talking about. And also, If the client is a webserver would you rather have the webserver doing stuff like sorts, instead of serving webpages? Another problem is the huge amount of unecessary network traffic you’ll get.
It’s IEnumerable<T> actually, but most of the objects that implemented IEnumberable will also implement the new generics based interface as well.