Deploy .NET w/o the Framework

[SentientPC]

Just thought I would post this, as the app/methods employed are pretty interesting for .NET devs. The samples on the page are interesting, as well.

Salamander .NET Linker and Mini-Deployment Tool

Salamander .NET Linker and mini-deployment tool allows you to link .NET assemblies together into a single file, and to deploy your application without installation of the whole Microsoft .NET Framework. The linker selectively links MSIL code putting together only the required classes and methods, and it is capable of linking into the Microsoft .NET framework class libraries. The mini-deployment tool then builds a minimum set of the Microsoft .NET runtime to ship with your application. This usually results in installation size of a few mega bytes, rather than tens of mega bytes, and the installation takes much less time without rebooting machines. The mini-deployed application can be launched directly from a CD, absolutely without copying files or adding registry entries.

The mini-deployment tool puts together the minimum set of CLR runtime files and dependent assemblies that can be simply copied to a single folder on a target machine, and your application runs as if the whole framework is installed. Since the installation is isolated into a single folder, there will be no conflicts with future .NET installation. When linking is used for the dependent assemblies, it will further reduce the file size.

[jonathanclark]

> And regards the security implications, managed code running in the IE security zone has almost no rights. It can't do jack. And for that matter, have you ever tried to run .NET bits as applets in a webpage? I tried, and it's a pain in the ass and almost not doable. Running WinForms applications from IE? Tight ass permission set applies. No issue here.

I'm not saying .NET applets are useful/not useful to developers, I'm saying they pose a potential security risk. If you allow people to run abritrary code on your machine - any code, you are running a risk. For example, hypotherically suppose there is a bug in the native code for how .NET loads BMP files, someone could craft a BMP file that caused a crash/overflow and gain full access to your machine. MS has to be security hole free 100% of the time, while hackers only have to find an exploit once - this is not very good odds.

It's difficult to anticipate things that people might do to gain access. Java had the same problem, it was supposed to be a secure sandbox, but several exploits were found. Javascript is thought to be secure today, but when it interacts with other components... the following exploit can be used to gain access to almost all current Windows boxes because of the way it interacts with other components.

http://www.mikx.de/scrollbar/

I'm not famaliar how, but no doubt there are ways to disable IE from .NET code, so a large enterprise could apply this option to all of it's desktop when it is worried about this issue.

[Sn1p3t]

Actually, since .NET applications are managed code, you have complete access on what the application can access and do on your system.

It's funny how any .NET thread always ends with a mini flame war of .NET vs alternatives. Usually neither party knows enough about the other's solution to make a credible comment. Just go with what works.

VB6 apps required it's runtimes. Back then it was a pain, now no one really complains. I forsee this with .NET as well.

[smurfiness]

MS has to be security hole free 100% of the time, while hackers only have to find an exploit once - this is not very good odds.

But that's the way things are now, with or without .NET installed on the system. Sure, there MAY be security holes in .NET. But it's not like hackers have needed .NET to compromise Windows systems, is it?

[azcodemonkey]

I'd argue that a .NET app will be inherently more secure than an equivalent app written in C/C++ and take less time/money to write.

[John Veteran]

I'd argue that a .NET app will be inherently more secure than an equivalent app written in C/C++ and take less time/money to write.

I'd definitely agree with you that they take MUCH less time to create :woot: But I'd like to hear your reasoning as to why they're inherently more secure :huh:

[azcodemonkey]

Buffer overflows are a non-issue for .NET, unless someone is writing unsafe code and using char*, or unless I'm just plain ignorant of a way to overflow a string object... add to that code permissions, code signing, a robust cryptography API(not that it isn't available to non-managed code) and I'd say that you could write something to withstand exploitation. Also add to that that web apps are all server side, and a well-written web app is going to be hard to hack.

Ultimately, secure code is in the hands of the author. The platform itself may be vulnerable, but as dannysmurf posed, what makes that any different than a Windows box without the framework? And really, how is that different than any other platform other than Windows? In my mind, it's a red herring. The real issue to me is how well .NET reduces life-cycle, and in turn costs, and how easy it is to write maintainable code.

[jonathanclark]

I'm glad everyone read what I wrote :wacko:

While .NET is great about eliminating buffer overflows, .NET itself is written in C++ which is not so great about handling buffer overflows. I'm not arguing that C++ applicaitons are more secure than .NET application, that not the case - .NET apps are infinitely more secure against buffer overflows (and in general) than C++ because it has automate bounds checking built in.

The issue is .NET itself running on a computer, exposes the computer to security risk when it's made available to outsiders through Internet Explorer precisely because it's written in C++ and interacts with many system components that are run in "unmanaged mode". Microsoft must verify all unmanaged code that is accessable to .NET cannot have ill effects to your computer or it is sealed off through security restrictions. Sounds like an easy task, but it's not - and as I mentioned similar circumstances have arisen in the past with Java.

[azcodemonkey]

I wasn't really arguing with your post. :) I was answering gameguy's question of why I think a .NET app would be inherently more secure. As far as enterprise customers go, that's something they need to consider.

I was under the impression that a greater portion of .NET was written in C#. I'm sure there are underpinnings written in C/C++( like the interop mechanics ).

On your second point, I don't know how it really applies because I've never written any code that interacts inside a browser that could leverage .NET. I wouldn't even know where to begin with that.

[smurfiness]

jonathanclark: The fact that it runs in an unmanaged environment (Internet Explorer) isn't really relevant. The code itself is managed, which means that every action it performs must be OKed by the runtime.

It's certainly possible that there's a security flaw in the runtime that could allow an elevated privilege attack. But as I said, hackers hardly need .NET to pull something like that off now. I don't really see how putting .NET on your computer makes it any less secure than it already is with the current crop of ActiveX/scripting flaws that are in IE.

[aldo]

jonathanclark: The fact that it runs in an unmanaged environment (Internet Explorer) isn't really relevant. The code itself is managed, which means that every action it performs must be OKed by the runtime.

It's certainly possible that there's a security flaw in the runtime that could allow an elevated privilege attack. But as I said, hackers hardly need .NET to pull something like that off now. I don't really see how putting .NET on your computer makes it any less secure than it already is with the current crop of ActiveX/scripting flaws that are in IE.

Again, using .NET is just introducing more problems. It's just more code that can get exploited.

Look, .NET was a good idea. But it is going to fail in the exact same way Java did - and any sucess it will have is Microsoft dragging it through the hedge, which is what they are doing now.

I mean not only that, you have 3 Windows APIs to program for at the moment: Win32, WinForms and now WinFX. Winforms was stillborn, so people will not make huge investments into it only to find WinFX has overtaken it. But, WinFX is too far away - so what do people do? Go Web Apps or stick with Win32. Both ways Microsoft 'loses'.

[azcodemonkey]

I don't think so. ^^

My company is doing quite well with .NET selling development and education. The technology is new... quite new, and people are just recently getting budgets for development projects and training. Winforms is quite viable. We're waist deep in a smart client project.

The interest is there. It's just now gaining some momentum. Interest is peaked even more among developers with the next version coming down the pike.

BTW, where do you get that Java is a failure? Look at most enterprise level apps in the middle-tier(s). Guess what? It's more than likely Java.

How does MS lose if people choose web apps or win32? Most of our projects have been web apps. All of them were successful, and all ASP.NET. Hardly anyone does true win32 apps anymore. You're more likely to see MFC or ATL apps, or even more likely VB apps. If you're developing for the platform, MS wins.

[+LogicalApex MVC]

I'd definitely agree with you that they take MUCH less time to create :woot: But I'd like to hear your reasoning as to why they're inherently more secure :huh:

I havent read more than page 3 of this topic so far because your post caught my eye and i feel it should be properly answered.

.NET is more secure because its JIT compiled. This means the computer can decide what code it can and cant run, before the code is executed. Non-.NET apps run unrestrictidly on your machine. .NET Code Access Security changes this landscape dramatically.

For the poster that came after you stating that .NET is written in C/C++ and its more insecure than current methods. You are completly wrong. .NET is written in C#, the only part i would think could "possibly" be in C/C++ is the JIT compiler, but it could easily be written in assmbly since .NET isnt slower than C/C++ (actually in most cases faster). If you want proff of this, download .NET and run a DeCompiler on the MS runtime files. If they werent written in .NET it wouldnt be possible to decompiled them using a .NET DeCompiler. Also .NET apps support running in IE natively and without any changes needed by the developer (provided his app dosent need to do anything CAS (Code Access Security) will block. It is highly more secure than any other method simply because of the way its designed. The JIT compiler knows that code is about to be used before its used (it has to convert the MSIL (MS Intermediate Language) into Machine Language that the computer can execute) allowing it to enforce CAS. Since the JIT compiler wont compile any code that violates its policy's (meaning the app wouldnt even know about the error because the .NET runtime would just kill that code block) its practically impossible for a .NET app to break CAS.

For these reasons .NET is far more secure, if you are a .NET developer you can test my example by making a simple Windows Forms app. The app should attempt to open a file on the users HD. Run that app from your local machine and then copy the same file to a web server and see how CAS stops it from reading your HD.

P.S.: If you arent a .NET developer and would like to see this in action i can make a simple .NET app to do it and pop it on here, if anyones interested i will.

.NET has great default persmissions as well. Oh, BTW you can edit CAS settings for any .NET executable in the Control Panel!. Meaning if all spyware was written in .NET it would be possible for companys to easily prevent them from exectuting all together :o!.

[smurfiness]

I mean not only that, you have 3 Windows APIs to program for at the moment: Win32, WinForms and now WinFX. Winforms was stillborn, so people will not make huge investments into it only to find WinFX has overtaken it. But, WinFX is too far away - so what do people do? Go Web Apps or stick with Win32. Both ways Microsoft 'loses'.

Well, for one thing, Win32, Winforms and WinFX are three entirely different things. Win32 is a collection of about 60,000 DLL entry points used to manipulate everything from File I/O to encryption to on-screen painting, Winforms is a way to do UI in .NET, and WinFX is an umbrella term for an indexed file system, a graphics presentation system and a webservices interface. I don't know why you think that "people" have to choose one of those three things to the exclusion of the other two.

A better comparison would be between Winforms, Avalon/XAML or Win32 UI (three things that actually do the same thing). Even still, you don't have to choose any one of them, since they can all interoperate. I frequently use functions out of Win32 in my Winforms apps, and Winforms apps will work perfectly fine in the Longhorn context (and you'll even be able to mix and match them with Avalon apps). Winforms wasn't stillborn; it was a transition technology. It's called an upgrade cycle. It's certainly nothing new, and it's nothing to be afraid of, and if you plan on doing any serious programming ever, you're going to just have to get used to it.

Again, using .NET is just introducing more problems. It's just more code that can get exploited.

Well, by your logic, you shouldn't install a web browser or an email client or an IM client or any other application that connects to the Internet on your computer. Ever. All of those things contain "code that can get exploited." Even "the most secure browser," Mozilla, has security flaws. Since you are visiting this site in a web browser, you're obviously willing to make your computer less secure by installing those kinds of apps, so it seems to me that you're just FUDing here.

and any sucess it will have is Microsoft dragging it through the hedge, which is what they are doing now.

And I'm glad they're doing it. I'm tired of using creaky old APIs that were designed ten years ago (or more in some cases) and having to call those APIs with -- depending on what they do -- char* or const char* or LPSTR or LPCSTR or LPTSTR or LPCTSTR or LPWSTR or LPCWSTR or TCHAR or BCHAR -- NONE OF WHICH, by the way, are interoperable, and ALL OF WHICH, by the way, are insecure by default (alternately, int, unsigned int, UINT, long, LONG, LONGLONG, ULONG, ULONGLONG, LARGE_INTEGER, ULARGE_INTEGER, PULARGE_INTEGER... I could go on for a while with that).

My point being... the old way of doing things needs to change in a fast hurry. Microsoft realizes this, and even if they have to drag users and the majority of developers kicking and screaming into .NET, I'm all in favour.

[+LogicalApex MVC]

dannysmurf nicely put, agreed...

Finally had the time to read the whole topic. Funny how everyone thinks .NET is inherently insecure, but know nothing about the way it works. .NET is the future of Windows (and as Mono has it shaping up) and *Nix programming for a reason. Its more secure by default and its far more securable than ANY current method. Read my post earlier for a minor bit of understanding on why.

For all those about to scream .NET wont ever be highly welcomed in the Open Source world. MS made .NET a standard prior to releasing .NET 1.0 as well as the fact Novell has invested tons into .NET on Linux and other platforms. They plan on rewriting Gnome to be 100% .NET code in a few years...

Edited to add this link: Gnome to be based on .NET

[SentientPC]

Wow...this topic took an interesting route in the past few days :unsure:.

[Ultra Frosty]

First of all. I can compile a rich GUI application and it takes up 20KB. The only problem with .NET is that all of the functions and libraries and called in only when they are used, this is what slows down .NET. For example, you have only one button on a form, and that form opens a save file dialog box. When you click that button for the first time, the application has to pull the System.IO.dll file from your %WINDIR%\Windows.NET\Framework directory and load it into the application.

.NET may be easy, but I found that it isn't prime time just yet.

[Glowstick]

Delay DLL loading happens on regular applications too. Just run your favorite application with NTSD.exe and see all the module loads way after startup.

[darkmark327]

I had hoped MS would include the framework with SP2 so that the majority of people would wind up with it installed; it's a pain trying to get people to install that to run your program.

[aldo]

No, this is very simple.

If the .NET runtime gets 'owned', it means most likley every .NET app is insecure and will have to be recompiled. This is a risk most are unwillng to take.

RE: Java, it has failed on the desktop. Yes, it's heavily embedded in the backoffice systems, but this is not .NETs target. It's target is web front ends and rich clients. It's not high level, high performance, 99.999% uptime apps in the backoffice.

Of course we run web browsers and email clients, in an office I don't allow IM clients as they are too much of a risk, but web browsers and email is vital to most people, .NET runtime is not. Quite simple.

I mean... we already have a service pack out for this. How many more? Is it compatible with older versions? Clients are not going to like rolling out .NET framework (which is one of the biggest changes to Windows, much more than the VB runtime) every 6 months when MS decides it needs a 5th graphical toolkit.

Yes, I know I sound very boring and way too strict on my policies, but when a big company needs these kind of solutions, millions can be lost if it goes wrong.

[Glowstick]

If the VC/BC/Delphi/whatever runtime libraries are owned, every app compiled with it is insecure. If the operating system is owned, every app running on it will be insecure. Yadda, yadda.

Stop your goddamn scaremongering. Sheesh.

[John Veteran]

And I'm glad they're doing it. I'm tired of using creaky old APIs that were designed ten years ago (or more in some cases) and having to call those APIs with -- depending on what they do -- char* or const char* or LPSTR or LPCSTR or LPTSTR or LPCTSTR or LPWSTR or LPCWSTR or TCHAR or BCHAR -- NONE OF WHICH, by the way, are interoperable, and ALL OF WHICH, by the way, are insecure by default (alternately, int, unsigned int, UINT, long, LONG, LONGLONG, ULONG, ULONGLONG, LARGE_INTEGER, ULARGE_INTEGER, PULARGE_INTEGER... I could go on for a while with that). 

My point being... the old way of doing things needs to change in a fast hurry. Microsoft realizes this, and even if they have to drag users and the majority of developers kicking and screaming into .NET, I'm all in favour.

This is the #1 reason I hate using c++ now. I'm taking c++ classes and my instructors praise c++ like it's a gift from the heavens. I showed my instructor some C# last semester and she didn't like how all code MUST be in a class (because .NET is completely object-oriented). She said it creates a huge learning curve that most people wouldn't be able to get over. I disagreed with her and she kinda had this attitude like "well what would you know, I've been doing this for XX years and you're still learning it". I think it's more natural to think of programming with real objects instead of breaking everything down into a series of steps.

[darkmark327]

I don't like how C# loses some power...e.g. boolean typecasting and stuff like that (why can't they be warnings instead of errors? you'd still be making sure that people don't get stupid and screw it up)...but I hated that about Java too. All in all with all the annoying stuff that C++ requires it's a decent tradeoff.

[+LogicalApex MVC]

No, this is very simple.

If the .NET runtime gets 'owned', it means most likley every .NET app is insecure and will have to be recompiled. This is a risk most are unwillng to take.

RE: Java, it has failed on the desktop. Yes, it's heavily embedded in the backoffice systems, but this is not .NETs target. It's target is web front ends and rich clients. It's not high level, high performance, 99.999% uptime apps in the backoffice.

Of course we run web browsers and email clients, in an office I don't allow IM clients as they are too much of a risk, but web browsers and email is vital to most people, .NET runtime is not. Quite simple.

I mean... we already have a service pack out for this. How many more? Is it compatible with older versions? Clients are not going to like rolling out .NET framework (which is one of the biggest changes to Windows, much more than the VB runtime) every 6 months when MS decides it needs a 5th graphical toolkit.

Yes, I know I sound very boring and way too strict on my policies, but when a big company needs these kind of solutions, millions can be lost if it goes wrong.

From everything you have said its very well aparent you dont know anything about .NET...

1. .NET supports side by side installations as it ends "DLL Hell" so if you used an app that bare faced needed .NET 1.0 you can install 1.0 and use it. Installing .NET 1.1 or 2.0 or all 3 wouldnt break any other .NET runtime installation.

2. You dont know anything about .NET security. No .NET application compiles to machine code, it all compiles to MSIL (MS Intermediate Language) which is then compiled to machine code by the JIT compiler. This allows .NET to enforce CAS which allows YOU (yes you can adjust CAS for every app you use thats based on .NET runtime) or MS if need be prevent an app from doing certain things. With CAS the application code thats in question does NOT get compiled. So it cant be worked around as .NET wont even let the code run.

If that "did" manage to get broken its no different than whats used now. Tons of apps use IE internally, 99.98% of Windows applications make use of the Win32 API. So hiding from .NET because it may some day be hacked is stupid. There are very very very few apps on any operating system that dosent make use of shared library's from another party (OS, Third-Party Developers, etc.)

3. .NET is used on very critical systems that need monumental uptime, Ebay is powered on .NET (as one example). Due to the way .NET is archetectured its actually alott better designed for mission critical systems than using Win32 API or most other methods.

MS releases service packs to fix problems just like any other software company. This happens with any piece of software. The service packs are generally backwards compatible with the same .NET runtime its designed for, but if they make say a security change it can affect some software. As happens with any runtime, but MS makes developers well aware of any possible problems.

4. I have no idea what you mean by MS decides to release a completly new runtime version every six months. .NET is over 2 years old is only nearing its 3rd release. As explained in #1 it supports side by side installations you dont have to install 2.0 till you use an app that needs it and it wont bother your 1.1 install or 1.1 based applications.

I think you should understand a technology before you aim to discredit it...

If you were more knowledgable you would embrace .NET alott more because it gives you 100% control of the applications on your computer. If you didnt trust an application you could modify CAS settings to prevent the app from writing to the HD or the Registry and then run it and test it out. That would prevent it from damaging your computer. A system admin could also prevent certain applications from running period, or limit what they do. All this is doable w/o any work from the developer and the developer cant change your settings.

Now i just please ask that people that dont understand a technology stop commenting negative on a technology unless you can actually back up what you say!!

[aldo]

Ok, I'm not actually saying that you get DLL Hell. I am refering to the fact you need to upgrade everyone to 2.0, which just means every time you need to take advantage of another feature, and you compile for 2.0, you need to get everyone to upgrade. Out of the small amount of people that have .NET, another smaller will have 2.0.

You also misunderstanded me on the hacked idea. I am saying if there is a vunrability inside of the .NET runtime which allows buffer overuns for example (something that many people forget to check now it is handled by .NET), it means every app is insecure. It doesn't matter what CAS setting you have set if the runtime itself has been comprimised.

As for 3, it doesn't matter to me if ebay runs it. I couldn't give a crap, because at the moment I would not think about deploying .NET until MS release a final, finished .NET spec and runtime so I don't need to worry about upgrading it.

4: ok. 9 months insetaed of 6 months. Big deal, it's still way too much for a supposedly 'secure' runtime. The VB runtimes were tiny and were only upgraded every 2 or 3 years.

I mean, it's not me thats fighting this, read Joel Sposkey's article about How Microsoft lost the API war: http://www.joelonsoftware.com/articles/APIWar.html

Read that...

[darkmark327]

None of your points are any more relevant than they were:

Ok, I'm not actually saying that you get DLL Hell. I am refering to the fact you need to upgrade everyone to 2.0, which just means every time you need to take advantage of another feature, and you compile for 2.0, you need to get everyone to upgrade. Out of the small amount of people that have .NET, another smaller will have 2.0.

Different somehow than when MS releases upgrades and service packs for operating systems? Much software is only compatible with specific minimum service packs.

You also misunderstanded me on the hacked idea. I am saying if there is a vunrability inside of the .NET runtime which allows buffer overuns for example (something that many people forget to check now it is handled by .NET), it means every app is insecure. It doesn't matter what CAS setting you have set if the runtime itself has been comprimised.

Different than if vulnerabilities exist in any other facet of windows and allow your box to get 0wned? As for your buffer overrun theory, you don't have to check for overruns because .NET handles all that. So instead of worrying about if EVERY software has overruns, you only have to consider whether .NET does, which is very unlikely, and even so, no more dangerous than if anything else in windows allows such an exploit. You also assume every piece of software written in .NET uses the part of .net with this hypothetical exploit.

As for 3, it doesn't matter to me if ebay runs it. I couldn't give a crap, because at the moment I would not think about deploying .NET until MS release a final, finished .NET spec and runtime

What do you consider a final, finished spec? Apparently not a 1.0 release, or even a service pack for it, or even a 1.1 release. Or perhaps you consider software finished when it's never updated again. Therefore I assume you use Windows 95, since all the later OSs are updated from time to time so therefore they're unfinished.

so I don't need to worry about upgrading it.

What OS/Service pack you running?

4: ok. 9 months insetaed of 6 months. Big deal, it's still way too much for a supposedly 'secure' runtime. The VB runtimes were tiny and were only upgraded every 2 or 3 years.

Same as above with obsolescence.

I mean, it's not me thats fighting this

You sure had me fooled.

Edited August 31, 2004 by darkmark327