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.

[+LogicalApex MVC]

Very nice example darkmark327 :D

[em_te]

You should read up on what i have said previously on .NET security in this thread. What you are saying makes very little sense...

What you said earlier about .NET security has little applicability to hackers. Yes, .NET is permission-based so that applications cannot access the system. And yes, .NET uses managed code so that memory is not illegally accessed. But all that does, is stop a .NET application from performing malicious actions. A hacker would probably sidestep all that and attack the code parser or bugs in the other framework libraries (which usually have higher privileges such as System.Reflection). That's how it's been done in the past with other VMs. For example, a malformed file could crash the code parser before it even gets to the JIT compiler or poor programming logic in the libraries could allow privilege escalation. How many times has Microsoft had to patch the Microsoft Java VM because there were security holes? Don't forget that the MSJVM is built with similar concepts to .NET.

It is agreed that you shouldnt install things you dont need, but with the increase in applications written on the .NET framework having it installed can make it easier on users. Again installing the .NET framework isnt more of a "Security hole" than installing the OS itself (which .NET is far more safe than).

Making it easier for users has nothing to do with security. Often it is the case that making things easier is usually a comprimise on security. Should Microsoft bundle every single software in the world to make it easier for users? I never said that the .NET Framework was a "security hole" but having it installed just creates more things for you to patch when updates are released. By the way, I hope you've installed SP1 for the .NET Framework because it patches several vulnerabilities.

Huh? Again you show your extreme lack of knowledge in .NET...

MS released .NET as a standard as i already said (if you are technical enough you can read both standards documents here (C# Spec.) and here (CLI Spec.)). Those standards are what Mono is built upon. That is the reason Mono based apps CAN run on the MS .NET Framework and vice versa (provided Mono supports the librarys being loaded as Mono isnt complete yet).

Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

Maybe one day we will get true techs speaking on tech related topics. I'm getting very very sick of these self proclaimed techies that know nothing of what they choose to speak on. Heres a nice hint of advice...

If you dont know what your talking about, don't talk about it!

I apologize for making myself sound like an idiot. I had no intention of lying.

[The_Decryptor Veteran]

Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

The MSIL code layout is a standard, that's why the people behind mono didn't have to reverse-engineer it

the entire C# language is a standard, same with the compiler.

ms standardised the CLS, which is how the languages can interoperate, by making everything strongly typed and shared.

the way that the framework calls are made (e.g. to System.Xml.XmlSerializer) is the way ms wrote it, it isn't a standard and ms are not protecting it.

The only things Microsoft didn't standardise are Windows only API calls, like the System.Windows.Forms namespace

But, i might be wrong about some of the information, i read about it ages ago.

[aldo]

The MSIL code layout is a standard, that's why the people behind mono didn't have to reverse-engineer it

the entire C# language is a standard, same with the compiler.

ms standardised the CLS, which is how the languages can interoperate, by making everything strongly typed and shared.

the way that the framework calls are made (e.g. to System.Xml.XmlSerializer) is the way ms wrote it, it isn't a standard and ms are not protecting it.

The only things Microsoft didn't standardise are Windows only API calls, like the System.Windows.Forms namespace

But, i might be wrong about some of the information, i read about it ages ago.

Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

[azcodemonkey]

Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

Copying an API isn't stealing. Copying the implementation is stealing. Besides, Mono is developing Gtk# for Linux windowing and Cocoa# for Mac. Neither of those libraries has anything to do with Win32.

[+LogicalApex MVC]

What you said earlier about .NET security has little applicability to hackers. Yes, .NET is permission-based so that applications cannot access the system. And yes, .NET uses managed code so that memory is not illegally accessed. But all that does, is stop a .NET application from performing malicious actions. A hacker would probably sidestep all that and attack the code parser or bugs in the other framework libraries (which usually have higher privileges such as System.Reflection). That's how it's been done in the past with other VMs. For example, a malformed file could crash the code parser before it even gets to the JIT compiler or poor programming logic in the libraries could allow privilege escalation. How many times has Microsoft had to patch the Microsoft Java VM because there were security holes? Don't forget that the MSJVM is built with similar concepts to .NET.

Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

For those reasons you cant use a .NET application to circumvent .NET. I recommend you read up on .NET CAS before you speak on that subject...

Making it easier for users has nothing to do with security. Often it is the case that making things easier is usually a comprimise on security. Should Microsoft bundle every single software in the world to make it easier for users? I never said that the .NET Framework was a "security hole" but having it installed just creates more things for you to patch when updates are released. By the way, I hope you've installed SP1 for the .NET Framework because it patches several vulnerabilities.

It is agreed that less security means more user friendly and its probably not in MS's best intrest to bundle .NET with windows until Longhorn. That way they dont have to worry about supporting .NET on end-users machines until its a core part of the OS. The reason .NET i mentioned its not a bad idea for users to install .NET is because it dosent produce more security holes. The very nature of .NET makes it safer than the Win32 API. The .NET runtime also wouldnt be activated except by .NET appications.

Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

Actually all the core parts of .NET is standardized... Did you even look at the standards? i did link you to them in my last post. The C# language is a standard as well as the CLS (Common Language Specification) this means a JIT compiler can be written that can understand MSIL as well as a language that can produce MSIL.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

No the reason why Mono runs .NET so successfully is because its based on the MS .NET standards. That ensures they arent "reverse engineering" and getting hit with suprises along the way. Since MSIL is a standard that the Mono developers can build upon they only have to read MS .NET FCL (Framework Class Library) documentaion on how non-open API's should work. They can then code their own API that will do what the MS API would do without needing to "Reverse Engineer".

Maybe you should read the Mono projects FAQ for some enlightment: Mono FAQ: General Mono FAQ: Tecnical

BTW: Do read the linked documents this time...

[Sn1p3t]

Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

[snipped]

You = my hero :p

I think the main problem facing .NET is the general feeling that most developers have for Microsoft. A large, unfeeling company who has complete control over your development. Nothing could be further from the truth.

.NET is here to stay. Microsoft has invensted a LARGE amount of time and money into developing a Framework that would work anywhere, from mainframes, to console applications, to web applications.

When VB 6 applications where first released, no one had the runtimes. Truth be told, a ~6MB download for VB6's runtime is slighly less annoying than .NET's 21MB framework, but the surge of broadband should be enough to offset this one-time "annoyance".

.NET allows developers much greater RAD, simply because they spend less time securing their application, which everyone does, and more time writing what they need. Some can argue "I'd rather develop my own security. Who trusts Microsoft?". However, especially for beginning developers, it's much easier to leave your security to a company who's had years to refine (and learn from their mistakes) their security.

.NET was built with security and RAD in mind. My only gripe is that by nature, compiled code isn't secured, as it exists in easily decompilable MSIL. Obfuscation is a simple and easily available alternative.

Reguardless of what other people may think, Microsoft makes some quality products. The next version of Visual Studio is likely to be a huge hit, especially with the inclusion of intensive testing and debugging features.

The problem is, .NET is a (relatively) new developing platform, and one that I feel will grow fast. There are many features the framework provides that secures your application by default.

One last thing, I heard some comments quite a few pages ago stating that if a problem was found in the Framework, all applications would have to be recompiled. Nothing is further from the truth. A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

[+LogicalApex MVC]

You = my hero :p

I think the main problem facing .NET is the general feeling that most developers have for Microsoft. A large, unfeeling company who has complete control over your development. Nothing could be further from the truth.

[truncated - original post above]

Thanks for the comment :cool:

I'm glad to see someone in this topic have a brain as it started to seem like no one here could read (which is a 2 part process, reading the words and comprehending what you have read). Thanks for the much needed eye opener :D...

Very good post as well as i agree with your points as will anyone who is actually knowledgable in .NET.

[darkmark327]

One last thing, I heard some comments quite a few pages ago stating that if a problem was found in the Framework, all applications would have to be recompiled. Nothing is further from the truth. A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

[Sn1p3t]

Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

I assume you weren't being sarcastic :p

BTW: On your WeatherAlert thread (very nice program BTW), you should mention that the .NET framework automatically allocated more memeory than it needs for security / performance reasons. If your computer needs this memory, it frees it up. The fact that it's using 30MB of memory means that you don't need it, and shouldn't complain :p

[darkmark327]

It is pointed out in a small fracas early in the thread.

[smurfiness]

A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

Well, for one thing, your program is not "broken;" ie it still functions. There's a UI bug in the Framework that now affects your program. That's partly your own fault. SP1 was available as a public beta for some time, and you SHOULD have taken the time to test your program with the new bits then so that you could have reported any bugs you found and maybe gotten them fixed before the SP shipped. Instead, you just assumed that everything would work flawlessly through the upgrade and didn't even give the .NET 1.1SP1 scenario a cursory test.

What the poster you quoted said is completely relevant. If Microsoft released a fix for the Framework that fixed your groupbox problem, you wouldn't need to recompile your application to take advantage of that fix.

Although I might agree with your opinion on your presidential election, I don't see how that's really relevant to a discussion about the .NET Framework.

[The_Decryptor Veteran]

Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

Say you wrote a API set, now i come along and make a implementation of it for Linux or whatever, I'm am not copying anything off you, i am only exposing my code in the same way i you do, if i decompiled your API's and wrote mine off your's, that would be a DCMA thing.

When the mono project implemented the System.Windows.Forms namespace, they didn't decompile the System.Windows.Forms.dll assembly, they wrote their own wrapper based around wine, exposing their own code callable in the same way that ms wrote their's, that why ms don't care, they are not copying there work in any way, just the way you call it.

[Sn1p3t]

(From the WeatherAlert thread)

I know it does up a lot of memory when it's not minimized  ; that's just how the framework works. C# was easy enough to pick up, but muddling through full-fledged C++ for something like this is sorta overkill (but I may end up doing it anyway ). But I think of it this way: when you're looking at the full weather information, it's probably not going to be when you're in the middle of playing a game or things like that; you'll have it minimized when you're doing intensive stuff, and when it's minimized it takes up very little memory. That and the fact that I have ample RAM. I guess. *shrug*

Um, you're making it into a problem. If you were t be running it with Doom III in the background, it would take VERY VERY little RAM, not the ~15MB that it uses when no other applications are running. A lot people aren't going to like the application just for that reason.

[darkmark327]

It takes up a lot of RAM even in low memory situations, though. My family's machine has a meager 256 taken up almost entirely, and WeathAlert still contributes a lot to its use.

[Sn1p3t]

I have attached a picture that shows this. I have 512MB of physical RAM.

[em_te]

Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

For those reasons you cant use a .NET application to circumvent .NET. I recommend you read up on .NET CAS before you speak on that subject...

I beg your pardon of my ineptitude in English.

In thinking about security, it is necessary to think outside the box. Basking in its supported features does not help in analyzing its unknown deficiencies. The .NET Framework is a huge thing and statistically speaking, it is inevitable that programming errors will be found. They do not necessarily need to be errors where rogue code is executed. It can be errors where checks are improperly checked. The question is whether the .NET Runtime and it's interaction with the OS can contain those errors from being exploited. For example, here's a typical route for a .NET application.

1) The .NET Runtime or the web browser makes a call to an HTTP server to download some .NET code. At this stage, an attacker can exploit bugs (if exists) in the .NET Libraries or the web browser to falsify its originating domain in order to gain higher privileges. For example, the attacker could use cross-site script injection exploits to inject code into the site on another domain. The attacker could also use malformed HTTP headers to falsify the domain.

2) The parser checks that the downloaded file conforms to the IL specification. The parser also checks for code signatures, domains, and other forms of evidence. At this stage, an attacker could exploit bugs (if exists) that allow it to bypass those checks. Signatures are difficult to exploit except perhaps with buffer overflows. .NET supports a XML based signature system which opens it up to XML parser attacks. Domain information can be falsified as in the preceding stage.

3) Then the parser checks that the libraries referenced in the code exist and if necessary, downloads those additional libraries. It also checks for permission to use those libraries. At this stage, an attacker could exploit bugs (if exists) to bypass permission checking. For example, a recent bug in Sun's Java VM allowed code to be initialized in a reserved namespace (java.*) because the classloader forgot to check for slashes in the namespace.

As you can see, even before the code gets loaded into it's managed environment, there are plenty of areas where it is still exploitable. The exploitation may even involve deceiving the CAS.

It is agreed that less security means more user friendly and its probably not in MS's best intrest to bundle .NET with windows until Longhorn. That way they dont have to worry about supporting .NET on end-users machines until its a core part of the OS. The reason .NET i mentioned its not a bad idea for users to install .NET is because it dosent produce more security holes. The very nature of .NET makes it safer than the Win32 API. The .NET runtime also wouldnt be activated except by .NET appications.

That assumes that typical users use enough .NET applications that warrant its existence on the OS.

Actually all the core parts of .NET is standardized... Did you even look at the standards? i did link you to them in my last post. The C# language is a standard as well as the CLS (Common Language Specification) this means a JIT compiler can be written that can understand MSIL as well as a language that can produce MSIL.

Could you point out to me where the System.Windows.Forms namespace is standardized in the ECMA links you sent me. I myself could not find them there. If they are not there but are present in .NET Framework then that implies that not all parts of the Framework are standardized.

No the reason why Mono runs .NET so successfully is because its based on the MS .NET standards. That ensures they arent "reverse engineering" and getting hit with suprises along the way. Since MSIL is a standard that the Mono developers can build upon they only have to read MS .NET FCL (Framework Class Library) documentaion on how non-open API's should work. They can then code their own API that will do what the MS API would do without needing to "Reverse Engineer".

That's fine but I'm arguing that the Microsoft .NET Standards are not the same as the ECMA C#/CLR standards. I'm arguing that Microsoft's Standards are a combination of open standards and proprietary standards. Sure, if Mono followed Microsoft's .NET Standards then they will gain complete interoperability. But if they only followed the ECMA standards, they will not be completely interoperable.

Take, for example, this quote from MSDN:

The System.Windows.Forms namespace contains classes for creating Windows-based applications that take full advantage of the rich user interface features available in the Microsoft Windows operating system.

If it takes full advantage of the rich user interface, then by nature that API will contain code that will only work on Windows (or WINE).

[The_Decryptor Veteran]

Could you point out to me where the System.Windows.Forms namespace is standardized in the ECMA links you sent me. I myself could not find them there. If they are not there but are present in .NET Framework then that implies that not all parts of the Framework are standardized.

That's fine but I'm arguing that the Microsoft .NET Standards are not the same as the ECMA C#/CLR standards. I'm arguing that Microsoft's Standards are a combination of open standards and proprietary standards. Sure, if Mono followed Microsoft's .NET Standards then they will gain complete interoperability. But if they only followed the ECMA standards, they will not be completely interoperable.

I think your confusing the managed api's with the framework, the framework is a system for running and building managed applications, the api's are a different section, the api's don't have to be standardised, because they are in essence a separate section, but ms wont change the layout because if they did, all .net apps would have to be recompiled, and if you notice, ms are good on backwards compatibility (how do you explain the Win16 api's and vm being in longhorn, ms are still supporting use of it) that's why mono will work, ms wont change the api layout, so mono can implement it.

http://msdn.microsoft.com/net/ecma/

Also, i don't get the section your saying about the ms standards and the ecma standards being different , they are the same thing, ecma didn't come up with them, microsoft did.

[darkmark327]

This seemed to have some relevance to at least one side of this ridiculous debate. http://www.eetimes.com/sys/news/showArticl...icleId=47205205

specifically this idea

If programmers are not prepared to widen their horizons to avoid losing jobs to outsourcing, they should consider another line of work

[The_Decryptor Veteran]

Good point

What was the line, those who refuse to evolve will become extinct

.NET is the future, if you spend all your time saying you wont upgrade to it, you will get left behind without experience in it.

I recommend a mod close this thread, it's gone off-topic and most of it isn't even making sense now.

Edited September 16, 2004 by The_Decryptor

[em_te]

I think your confusing the managed api's with the framework, the framework is a system for running and building managed applications, the api's are a different section, the api's don't have to be standardised, because they are in essence a separate section, but ms wont change the layout because if they did, all .net apps would have to be recompiled, and if you notice, ms are good on backwards compatibility (how do you explain the Win16 api's and vm being in longhorn, ms are still supporting use of it) that's why mono will work, ms wont change the api layout, so mono can implement it.

http://msdn.microsoft.com/net/ecma/

Also, i don't get the section your saying about the ms standards and the ecma standards being different , they are the same thing, ecma didn't come up with them, microsoft did.

Here's a quote from the .NET Framework website:

The .NET Framework is composed of the common language runtime and a unified set of class libraries.

And it makes sense from an object orientated perspective because all classes must be derived from a base class and that base class is a member of some library. Even the simplest "Hello world" application will have to use classes from a library (for IOs and Strings). ECMA-334 and ECMA-335 defines those things and Microsoft's .NET Framework implements them. I'm arguing that Microsoft's .NET Framework implements more then those things but also their own proprietary set of libraries which are not standardized with the ECMA. People who then write .NET Applications using Microsoft's set of libraries (de facto standards) will not be compatible with one that implements only the ECMA defined libraries (de jure standards).

[azcodemonkey]

And it makes sense from an object orientated perspective because all classes must be derived from a base class and that base class is a member of some library. Even the simplest "Hello world" application will have to use classes from a library (for IOs and Strings). ECMA-334 and ECMA-335 defines those things and Microsoft's .NET Framework implements them. I'm arguing that Microsoft's .NET Framework implements more then those things but also their own proprietary set of libraries which are not standardized with the ECMA. People who then write .NET Applications using Microsoft's set of libraries (de facto standards) will not be compatible with one that implements only the ECMA defined libraries (de jure standards).

That would be true if they used Windows Forms currently. I may be wrong, but Mono is trying to keep same API, but have GTK and Cocoa be the underlying technologies.

A quote from the Mono site:

Question 5: Will you implement the .NET Framework SDK class libraries?

Yes, we will be implementing the APIs of the .NET Framework SDK class libraries.

Question 6: Will you offer an ECMA-compliant set of class libraries?

Eventually we will. Our current focus is on inter-operating with the Microsoft SDK, but we will also offer an ECMA compliant subset of the libraries.

Smart, if you ask me. Can MS touch them? Only if they find they're stealing code. An API is a public set of interfaces to program against, key word being interfaces. How those interfaces are implemented(if someone stole MS's implementation) is the only thing MS can go after someone on, otherwise, they'd be killing WINE. This is where DMCA is really going to be tested. Reverse engineering has always been how our technology has evolved. Some companies are trying to use the DMCA to change that.