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.

[Jerry Grey Member]

Cool! thanks, this need to be pinned, because this is ask a lot..... :D

[+virtorio MVC]

$489? Its cheaper just to deploy the framework.

[Jerry Grey Member]

$489? Its cheaper just to deploy the framework.

Yea, I agree there when I found out you have to pay. :o

[smurfiness]

That's actually pretty cheap for Salamander. Their other tool is almost $2000.

[Jerry Grey Member]

That's actually pretty cheap for Salamander. Their other tool is almost $2000.

Really? But if a program is that much money why pay for it? :blink:

[SentientPC]

I am not endorsing it...I was just pointing out that the idea is interesting (decoupling only the needed portions of the framework). It would be nice to see an open source version of a product such as this.

Actually, it would be neat to see a VS compiler option for this, but I can pretty much bet that will not happen ;).

[John Veteran]

OK, stop for a second and think. What about the people who do have the framework installed already? :huh: For them, your app is extremely large, and with each service pack to the framework, you have to issue a new update, because the service pack they install doesn't affect your program.

There are other reasons not to do this too, but everyone is so hellbent on using C#/VB.NET without the framework (for reasons I cannot fathom) that they don't see them :wacko:

[Mordkanin]

but everyone is so hellbent on using C#/VB.NET without the framework (for reasons I cannot fathom) that they don't see them :wacko:

Really. You'd think they'd realize that the .NET framework is just a very nice set of libraries that make the lives of programmers much easier.

[Jerry Grey Member]

Really. You'd think they'd realize that the .NET framework is just a very nice set of libraries that make the lives of programmers much easier.

Yea, .NET framework makes programming very easy.. :yes:

[smurfiness]

There are other reasons not to do this too, but everyone is so hellbent on using C#/VB.NET without the framework (for reasons I cannot fathom) that they don't see them :wacko:

A couple of reasons for that (admittedly, I WAS one of those people at one time, but my own experience distributing a .NET application has given me an attitude adjustment). First, they think that it will decrease the amount of downloading that their users will have to do (Untrue. A WinForms app would require about 16MB of the 20MB Framework).

Second, there's a stigma attached to .NET. Amateurs think that if they don't have to say that their app requires .NET, people will be more likely to download it. That's not actually their real problem; it's just their perspective on their problem. The actual problem is that they just haven't written something good enough to warrant a 20MB prerequisite download (if you write something that people want and make it good, they will download whatever requirements are necessary to run it).

[SentientPC]

A couple of reasons for that (admittedly, I WAS one of those people at one time, but my own experience distributing a .NET application has given me an attitude adjustment). First, they think that it will decrease the amount of downloading that their users will have to do (Untrue. A WinForms app would require about 16MB of the 20MB Framework).

Second, there's a stigma attached to .NET. Amateurs think that if they don't have to say that their app requires .NET, people will be more likely to download it. That's not actually their real problem; it's just their perspective on their problem. The actual problem is that they just haven't written something good enough to warrant a 20MB prerequisite download (if you write something that people want and make it good, they will download whatever requirements are necessary to run it).

While I tend to agree with these observations, there are also some valid reasons why this could be good.

As you alluded to:

There are still many low-end machines that are not suitable for .NET framework installation, and some users may not be willing to install the framework at all, this tool helps you to reach more customers as it silently deploys a trimmed down version of the framework without any noticeable effects and conflicts. The framework appears as an integrated part of your own application.

I think there is a lot to be said by that. I think some people hear "Requires the .NET Framework" and immediately get turned off, as ridiculous as it may be (Thinstall claims "~6MB for a typical GUI application"). If you can get past the marketing speak, I think they bring up some valid points here (although a little dramatized in some places, ie "3700% less space" ;)):

1. The .NET Framework adds more that 20MB to your application download. How many users are you losing because of the extra 1-3 hours of modem download time?

Thinstall creates a stand-alone application that runs without the .NET Framework in as small as 2.7MB for a simple Hello World, and ~6MB for a typical GUI application.

2. The installed size of the .NET Framework is more than 100MB. How many users will decide to uninstall your application because it takes up too much space?

Thinstall runs .NET EXEs without decompressing any files to disk, so the download size and install are exactly the same. i.e. 2.7MB versus 100MB, or 3700% less space.

3. Users are afraid of installing the .NET Framework. Users have a short attention span, don't waste time trying to convince them they need to install 2 things to run your application. When you have the user's attention, sell them on your application, not on why they need the .NET Framework.

Thinstall combines your program with the required portions of the .NET Framework to form a single EXE that runs without installation. No files are extracted/installed to the hard drive, the application can be run directly from CDROM or Internet download link.

4. The .NET Framework install requires registry write access and is not possible for Guest accounts on 2k/xp. Guest accounts are very common in large corporate and educational institutions. Guest users cannot evaluate your software for purchase without contacting the IT department, which leads to lost sales.

Thinstall allows .NET applications to run without registry permissions on all windows Accounts.

5. The .NET Framework install fails on more than 1% of computers because the user's computer is "broken" from previous installers or viruses. It's not your job to trouble shoot why the .NET Framework installer isn't working!

With zero installation, Thinstall runs .NET applications on PCs with corrupted registries, missing DLLs, broken MSI, etc.

6. Your application may not be compatible with newer or older versions of .NET Framework. Don't waste your time tracking down bugs that aren't your fault.

Thinstall links a specific version of the .NET Framework with your application, so it runs exactly the same every time.

Are you worried about lost sales from hackers removing licensing code from your .NET application?

1. Even with obfuscators applied, .NET applications can be perfectly disassembled and reassembled.

This makes it very easy for any programmer to find your license code and remove it. Once a "crack" for your application is released on the net you can stop it. Don't wait until it's too late.

Thinstall hides your .NET "byte-code" from all external disassemblers and hacking tools.

[Glowstick]

Oh nice, first of all bump your executable by 5-10megs of size, and then just convince your computer to throw memory out of the window, if you'll be running multiple applications packed that way. Sure.

Either make your users download the framework, or lets just wait for Longhorn instead.

[SentientPC]

Tom Servo,Aug 29 2004, 12:06]Oh nice, first of all bump your executable by 5-10megs of size, and then just convince your computer to throw memory out of the window, if you'll be running multiple applications packed that way. Sure.

Bah, who doesn't like throwing away memory? :p

Either make your users download the framework, or lets just wait for Longhorn instead.

:) Nice Sig, btw

[smurfiness]

Something like that Thinstall tool might be useful in theory. But complex applications (which yours would have to qualify as if you're willing to spend $1500 on a .NET linker/obfuscator for it) are not distributed as single EXEs for perfectly good reasons, which is exactly what the Thinstall tool appears to do.

And as was already said, you can't apply a .NET service pack to an application that's been linked like this. If Microsoft ever has to release a critical patch for the Framework (say, because there's a buffer overflow in System.String), you are S-C-R-E-W-E-D. You'd have to redistribute your entire application to fix that. Which means a new round of testing to find out if the patch broke anything, then convincing all of your users to re-download the entire thing, possibly an at-your-own-cost mailing of new CDs to users if you're distributing that way (which could cost you a bloody fortune), and/or loss of future sales because you're selling something with security holes that can't be easily patched.

These tools just aren't worth the potential hassle. Distributing the Framework is safer, easier, and MUCH less expensive.

[The_Decryptor Veteran]

2. The installed size of the .NET Framework is more than 100MB. How many users will decide to uninstall your application because it takes up too much space?

The .NET Framework is about that size, your app isnt, it doesnt install the .net framework every time you install a app, it only installs once, it doest add the 100 or so MB to the app in the Add/Remove programs list, so that's not a valid statement.

[Glowstick]

The installed size happens only because IL code can be fairly good compressed, plus the framework installer creates NGen'd images of the core libraries, plus add application tracking and what not, that'll use up space slowly.

However can I see the issue here, when someone sees his Framework folder being around 120megs, he can blindly assume that the application needs most of this and would be some memory eating monster. You can witness a similar effect with those task manager eagle eyes, that don't want to understand how the CLR and GC handle system memory allocation.

[The_Decryptor Veteran]

Yeah, i see that happening all the time, e.g. this 100K app is using 17MB of ram, WTF is up with that!!??!!

Also, i agree with limecat :angry:

[anog]

Yeah, i see that happening all the time, e.g. this 100K app is using 17MB of ram, WTF is up with that!!??!!

so true, so true... :no: :no: :no: :no:

[azcodemonkey]

Yeah, i see that happening all the time, e.g. this 100K app is using 17MB of ram, WTF is up with that!!??!!

Also, i agree with limecat :angry:

The link explains all.

http://msdn.microsoft.com/library/en-us/cp....asp?frame=true

[Sn1p3t]

The link explains all.

http://msdn.microsoft.com/library/en-us/cp....asp?frame=true

Ah but the problem is most people don't understand that.

You have no idea how many people I have to convince that the overuse of RAM is OK. :p

[aldo]

OK, stop for a second and think. What about the people who do have the framework installed already? :huh: For them, your app is extremely large, and with each service pack to the framework, you have to issue a new update, because the service pack they install doesn't affect your program.

There are other reasons not to do this too, but everyone is so hellbent on using C#/VB.NET without the framework (for reasons I cannot fathom) that they don't see them :wacko:

Have you ever programmed in the real world?

If you have to distrubute a 20MB .NET framework with your app, which most users won't have (most users use 98, 2000 or XP without SP atm), over a dialup or ISDN connection, people will just not choose it. You have lost a sale.

Even if you have an internet deployment, most big places don't have the .NET framework installed.

1) Security: it's just introducing more holes into Windows.

2) More problems. .NET framework can horribly mess up a Windows install if you have problems with it - I've seen it plenty of times.

3) The fact you will have to keep upgrading it. They should of made a .NET framework 1.0, and kept with it. Sorted every bug and put any additional functionality they need in the app, instead of the framework. I know that many programmers just won't bother with .NET now, becuase if you want to take advantage of new VS stuff then you have to keep everyone uptodate on the huge .NET install.

4) Time. .NET framework can take ages on an old machine, and that means getting it booked into the workshop, transporting it around, having a tech watch over it... not only that, you have just took a working machine out of someone's office which means they may not be able to do a days work. If you have 1,000 machines all like that (running Win2000 for example), and you need to check each of them work fine after the install, you are looking at a couple of million dollars lost in work time.

Now do you guys get why no-one is taking up .NET and just using webapps? Whereas we used to 'recommend' custom wrote VB apps for businesses, we now give them a server, with Linux, Apache, mySQL and PHP installed - along with our custom web app we wrote for them, with a tape driver for automatic backups of the database, and usually roll out Firefox (we certainly will be pushing for this far more when it hits 1.0 or soon after) for security reasons. If it breaks, we SSH into the box, reboot if needed (or database restore - but we haven't needed to do this yet), and it's back up running within 5 minutes. Before, we'd have to goto the site, find where the files were stored, try and see what went wrong and it was a pain in the ass.

Upgrades are really easy too, we just overwrite the files at midnight and the new version is rolled out to all clients on the network. The next stage of course is to go to Linux desktops everywhere, which could be done due to the fact you only need a webbrowser, office suite and an exchange compatiable mail client (like Evolution).

I do like a lot of the features in VS.NET though - they could save us a little time. But sadly, for nearly all of what we do, 'rich client apps' are so passe. They have too many issues.

[kjordan2001]

Have you ever programmed in the real world?

If you have to distrubute a 20MB .NET framework with your app, which most users won't have (most users use 98, 2000 or XP without SP atm), over a dialup or ISDN connection, people will just not choose it. You have lost a sale.

Even if you have an internet deployment, most big places don't have the .NET framework installed.

1) Security: it's just introducing more holes into Windows.

2) More problems. .NET framework can horribly mess up a Windows install if you have problems with it - I've seen it plenty of times.

3) The fact you will have to keep upgrading it. They should of made a .NET framework 1.0, and kept with it. Sorted every bug and put any additional functionality they need in the app, instead of the framework. I know that many programmers just won't bother with .NET now, becuase if you want to take advantage of new VS stuff then you have to keep everyone uptodate on the huge .NET install.

4) Time. .NET framework can take ages on an old machine, and that means getting it booked into the workshop, transporting it around, having a tech watch over it... not only that, you have just took a working machine out of someone's office which means they may not be able to do a days work. If you have 1,000 machines all like that (running Win2000 for example), and you need to check each of them work fine after the install, you are looking at a couple of million dollars lost in work time.

Now do you guys get why no-one is taking up .NET and just using webapps? Whereas we used to 'recommend' custom wrote VB apps for businesses, we now give them a server, with Linux, Apache, mySQL and PHP installed - along with our custom web app we wrote for them, with a tape driver for automatic backups of the database, and usually roll out Firefox (we certainly will be pushing for this far more when it hits 1.0 or soon after) for security reasons. If it breaks, we SSH into the box, reboot if needed (or database restore - but we haven't needed to do this yet), and it's back up running within 5 minutes. Before, we'd have to goto the site, find where the files were stored, try and see what went wrong and it was a pain in the ass.

Upgrades are really easy too, we just overwrite the files at midnight and the new version is rolled out to all clients on the network. The next stage of course is to go to Linux desktops everywhere, which could be done due to the fact you only need a webbrowser, office suite and an exchange compatiable mail client (like Evolution).

I do like a lot of the features in VS.NET though - they could save us a little time. But sadly, for nearly all of what we do, 'rich client apps' are so passe. They have too many issues.

Heh, something tells me you don't care much for Java either. ;)

[Glowstick]

1) Security: it's just introducing more holes into Windows.

Care to back THAT claim up?

2) More problems. .NET framework can horribly mess up a Windows install if you have problems with it - I've seen it plenty of times.

The .NET installer doesn't touch anything of the existing Windows installation, only a few registry keys. The rest is selfcontained in the %SystemRoot%\Microsoft.NET folder.

[jonathanclark]

Hi Guys,

Just found this interesting discussion and wanted to add a few comments.

>>1) Security: it's just introducing more holes into Windows.

>Care to back THAT claim up

When .NET is installed it allows .NET code to be run on from Internet Explorer with restricted security settings (just like Java applets). Right now there are no know security holes in this senerio, but it's very easy to imagine hackers will find several over the lifetime of .NET. So by installing the real .NET Framework you are potentially opening yourself up to risk that you wouldn't have if it weren't installed. This is one reason many enterprise customers refuse to install .NET on their PCs.

> The .NET installer doesn't touch anything of the existing Windows installation, only a few registry keys. The rest is selfcontained in the %SystemRoot%\Microsoft.NET folder

The .NET Installer writes thousands of registry keys and places many files in c:\windows, c:\windows\system32, as will as %system%\microsoft.net\framework. It also creates a new Global Assembly cache (c:\windows\assembly). It upgrades DLLs and for Windows 98/ME it installs device drivers. I know a developer who sells a retail application written in .NET with more than 100,000 copies sold already. Originally he installed the .NET Framework seperately and said that the .NET Framework fails to install on 1% of PCs (1000 machines is a lot of tech support calls). He switched to using Thinstall and doesn't have that issue any more.

[Glowstick]

The amount of files in system32 is negligible, just the few DLLs required to fire up the CLR. The registry keys are CLSIDs pointing to the class libraries. Registry keys don't do any harm at all.

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.