Develop Reference

Running winform application without .net framework

am developing a flash copy protect software with c#. The software is to remain on the flash drive(can not be transfered out or installed in the computer), it is a click and run software, no installation. I know that for it to work on other computers, the computer must have .net framework installed in it. I was thinking if it can be possible to add .net framework dll to the startup path of the application. If it will work, pls let me know and how to do it.
If there are other methods besides switching my project to C or C++, pls let me know. Thanks.

In normal .NET compilation (regardless of source language), the product is a (MS)IL - (Microsoft) Intermediate Language - dll. In case of executeables, it is given some native bootstrap code, a entry point, but it is still stricly tied to the Framework installation and works for nearly everything like a .NET dll. The Framework has to do the final IL -> Native Code translation. IL is a concept very similar to Java Bytecode, but with about 5 years of what works and does not work in Java.
.NET Native does not compile IL. It compiles hard, native code. Similar to the one any Native C++ (not to be mistaken with C++ .NET) compiler would make. The same a Delphi compiler would make. The same the Framework itself is written in. The final programm will have local copies of all the .NET .dll's it accesses. It is fully independant of any .NET Framework installation.

Install C# application on user system with system libraries

I have created a C# 2010 application and now when I install it on user application it asks for complete dot net framework. Is it possible if I can only put required dll files with my application instead of installing complete dot net framework on user machine ?

No it is not possible
The .NET framework is more than just assembly to copy on the target computer. It is a more complex infrastructure that interact with the OS when an executable is loaded and, if it contains IL instruction, it compile it just in time in order to have it running. So non chanches in order to me to have it working without a .NET framework setup, that can be done in a separate step, or by creating a Setup for your app with the proper framework version indicated as a prerequisite.
An overview of the framework can be found here, but many more others are available in the net, you should read it to understand why is not a just matter of functions you need or not.

You may choose to target .NET Framework Client Profile. That would decrease download size of .NET files. See this link for more details on subject: http://msdn.microsoft.com/en-us/library/cc656912.aspx#targeting_the_net_framework_client_profile

No, this is not possible. In order to install and run an application targeting the .NET Framework, the user must have the appropriate version of the .NET Framework installed on his/her computer.
If you want to make things easier, you should distribute your application with a setup program that ensures the .NET Framework is automatically installed along with your app. There's no reason the user should have to download and install the .NET Framework themselves. You can even create a setup program right from Visual Studio, so there's no excuse not to use one. It also makes managing dependencies and versioning conflicts much easier.
If you're really worried about the size of your dependencies and are targeting .NET 4.0, you can require only the Client Profile, which is a subset of the .NET Framework optimized for client applications. You'll have to set your project's Properties to target the .NET 4.0 Client Profile, and ensure that you're not using any of the assemblies it omits.
I hardly recommend wasting too much time on this, though. At last count, the Client Profile was only about 15–16% smaller than the full version—not an amount that makes much difference on the fast Internet connections found in most parts of the world today. And even less of a problem if you distribute on real media.
If you're absolutely dead-set on delivering an application without any dependencies (as comments to other answers suggest), you've got a hard road ahead of you. For starters, you'll need to drop .NET and C# entirely, and switch instead to an unmanaged language like C or C++. That's a very different programming environment than C#. Even if you're the best C# programmer in the world, there's going to be a significant learning curve to pick up C++.
And that still doesn't solve all of your problems. C++ applications compiled using a modern version of Visual Studio will still require that the appropriate version of the C Runtime Library be installed on the user's machine. This is, of course, a much smaller package than the entire .NET Framework, but you can't count on it always being there, so you'll need to install it along with your application.
Moreover, unlike the .NET Framework (which has WinForms, WPF, Silverlight, etc.) there is no GUI library bundled with C++. And if you choose any GUI library other than the native platform API (for example, Qt, which is quite popular for reasons that I still find inexplicable), that gives you an additional dependency. You mention Google's applications a couple of times as a model. Google Chrome targets the Win32 API directly and has written a bunch of their own code to draw their custom GUI on top of that base framework. That's really the only way you're going to eliminate dependencies entirely. And delay your app to market for a significant period of time.

Converting .NET App to x86 native code

There's a program written entirely in C# that targets .NET Framework 2.0.
Is there a way I could somehow compile (translate) managed EXE to a native one so it could be .NET-agnostic? I know there are probably commercial products for that purpose... but they are a bit expensive.
The problem is that we are to deploy the program on computers running Windows XP with no .NET Framework installed. There's also a requirement that the program's size must not exceed 500Kb (1Mb maximum) for it is downloaded from the web server (now the size is 255Kb). That is why there's no way we could attach a full-fledged .NET FX (or even a reduced one) to the downloaded program's file.
Obviously it is a terrible software engineering error that should have been detected and avoided earlier so we could use native technologies like C++ instead.
We have tried for now Novell's Mono - an open-source implementation of .NET Framework for Linux, MAC and Windows. Mono consists of C# Compiler, IDE, runtime (CLR) and Class Library assemblies (like System.dll and mscorlib.dll - much like .NET's class library assemblies installed to GAC).
What we tried to do is to locate CLR files and ship those along with our program's file and a few assemblies. This way the program can be invoked by running "mono program.exe" (command prompt) on a user's computer.
In addition to the inconvenience of such a use for the end user CLR files (mono.exe and mono.dll) turned out to be about 2.5 Mb in total that is much greater than the desired 500 Kb or even 1 Mb.
So, we have left with no other option but to translate our .NET App to a native one by a compiler, however the question remains - what compiler should we use and where could we find one...
For now I have stumbled upon a Singularity OS Project by Microsoft Research. It is an open-source research OS that is written in managed code (in part at least). The Singularity OS includes a Bartok compiler that the OS uses in order to translate a managed program to a native one (x86 32 bit). It should be noted that Bartok can't translate all the aspects of .NET 2.0 to a native code, but most of them. However I haven't yet learnt how to use the Singularity...
I would be really grateful to you if you could provide me with some useful tips and advice regarding the problem, your own experience with Singularity OS and Bartok Compiler or another approaches to the problem that I have overlooked and ways of solving it.
Thank you very much in advance!
Finally, using Mono's Full AOT feature (on Callum Rogers' advice) I've managed to produce a program.exe.dll that lacks a CLI header.
So it looks to me like a native dll. However I can't figure out how to convert that dll into exe or make it operational.
Also this dll doesn't seem to expose any functions of interest such as main function.

Check out AOT (Ahead Of Time) Compilation from the Mono project. This compiles your managed project into a native exe or an elf executable (depending on which system you target) that does not need the JIT. This is the technique used to get mono apps onto the iPhone (where the JIT/Framework are not allowed) and also has the added benefits of faster startup times, lower memory usage and it makes it harder for people to decompile your code. You said you were already using Mono, so it should be compatible.
Read up about it at the mono-project.com website and at Miguel de Icaza's blog (and iPhone info).
Note that you cannot use dynamic code or generic interfaces like
interface IFoo<T> {
...
void SomeMethod ();
}
And you will have to compile the DLLs of all the libraries you use.
PS: Make sure to use "Full" AOT for your problem.

2018 Update
At Build 2018, Microsoft announced .Net Core 3.0 roadmap that support Windows desktop applications (Winform & WPF)
2017 Update
For console apps, you can use .net core Self-contained deployments (SCD). Even for a hello world app, your package will 50MB+. You still need to install VC runtime though.
Update
As #jenix's comment, .NET Native is only for Windows Store Apps(UWP). After 3 years of it's announcement, this is still true, .net native for desktop may be dropped by microsoft . So this answer is not applicable anymore.
========
Microsoft Announced .NET Native Preview on Build 2014
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
Announcing .NET Native Preview
Microsoft .NET Native

There is a project called CrossNet that parses .Net Assemblies and generates unmanaged C++ code, that can be compiled in any standard compiler.

Not really a solution for .NET to native conversion, but maybe this helps: http://www.yoda.arachsys.com/csharp/faq/#framework.required

Not quite sure that there is much you can do besides painstakingly rewrite the application. To ease the already burdening process, you could disassemble the .NET application using something like Reflector (into Microsoft C++), and use that as a base to start and just replace managed C++ references with native ones.

Can you compile C# so it doesn't need the .NET Framework at runtime?

Is it possible to force the C# compiler to pull all the referenced calls out of the framework and pack them into dlls or even a single executable?
I like writing quick 'one-off' applications with C#, however I don't want to have to install the whole framework on the target machine once it's ready to go.

You ask a loaded question. C# is merely a language and does not require the .NET Framework. The process of compiling it requires a compiler, which may or may not itself take a dependency on the .NET Framework (Microsoft's C# compiler does not -- it is written in native code). Your program will need to reference some assembly where types, classes, and methods can be found for your use. You can remove system.dll and mscorlib.dll from your references list and reference your own assemblies. So you can avoid dependencies on the .NET Framework if you really work at it. But in the end, unless you have a C# compiler that compiles programs to native code you still have a dependency on the CLR.
That's a very technical way of saying... almost nothing. But it answers your question. :) More practically useful however is how to get your C# programs to run with a minimum of dependencies. mkbundle from mono will actually let you compile it all into an .exe with virtually no dependencies.
But if you want to stick with the Microsoft .NET Framework, you can achieve a much lighter footprint and faster install of the dependencies you commonly need by using the Client profile of .NET 3.5 SP1. You can read about it here:
http://msdn.microsoft.com/en-us/library/cc656912.aspx

Look at mkbundle using Mono.

It is now possible to compile C# to native code using Microsoft .NET Native:
https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx
It automatically compiles the release version of apps that are written in managed code (C# or Visual Basic) and that target the .NET Framework and Windows 10 to native code.
...
For users of your apps, .NET Native offers these advantages:
•Fast execution times
•Consistently speedy startup times
•Low deployment and update costs
•Optimized app memory usage
This only works with Visual Studio .NET 2015.

Take a look at the .NET client profile.
This will allow you to package a minimum install on the client machine.. which will later be updated by windows update to the full framework.
This depends, of course, on your app only using libraries that are contained in the client profile ...
Some info here: http://blogs.windowsclient.net/trickster92/archive/2008/05/21/introducing-the-net-framework-client-profile.aspx

It's said it is possible, using 3rd-party tools such as http://www.remotesoft.com/linker/

Not possible. Your "compiled" C# application is a language which the .Net CLR interprets (should have said JITed, Reads the IL, compiles to native code, and then invokes the compiled native code) at runtime.
FYI .net 2.0 is a standard install on xp SP2 and vista, so you won't be paying that much of a penalty.
You could look into mono, but this still involves running some kind of framework on your target machine.

This dependency which unfortunately frequently breaks or is missing in the real world is a big reason why C# has not had a wider adoption. On the flip side most development does have dependencies.. look at C++ & Java for example.
I don't think we will really get away from these dependency issues anytime soon, so I recommend that if you want to use C#, that you make a wrapper for installation which checks for the .net framework version dependency you need, and if missing notify the user that they need this to run your app.

Some C# features are bound to interfaces of the .NET framework.
For example:
yield return requires the IEnumerable interface
using (x) {} requires the IDisposable interface

Problems executing compiled 3.5 code on a server which only has the 2.0 framework

I can't seem to get my application up and running on my dev server and I'm not sure why.
I have compiled my code in VS 2008 with a target framework of 3.5. I am using 3.5 mainly because I have implemented LINQ rather extensively. Compiling and runs local without any problems.
The hang up is that my server only has the 2.0 .Net framework and upgrading to 3.5 is apparently not going to happen.
I was under the impression after doing some research that as long as I was trying to execute compiled code the server would not need 3.5 installed.
Today I am trying to publish to the server and I can't get past this error in my WEB.CONFIG
Configuration Error
Parser Error Message: Child nodes not allowed.
providerOption name="CompilerVersion" value="v3.5"/
EDIT ADD ON QUESTION:
I have seen some posts about possibly setting my references to "copy local" which might allow me to run on the 2.0 server. Thoughts?

You are right in that 3.5 runs on the 2.0 CLR, but 3.5 contains libraries and if you have used any of those, you're out of luck unless you install 3.5 on that server.
There are plenty of options for a 3.5 program to not run correctly on only 2.0, so I'd consider downgrading the program, or upgrading the server.
Note regarding copy local. Even if you copy all the 3.5 libraries that your app uses, there is no guarantee it'll work and most likely it won't. Even so, distributing the libraries with your app is expressively prohibited by the .NET license.
Since you have stated you use LINQ, the only legal way to get your app running is to install the 3.5 license.
Or, you can rewrite your app using only 2.0.

I'm pretty sure that LINQ is one of the things that makes 3.5 a requirement. A lot of the other things, like lambda expressions etc. are just compiler trickery.
Because System.Linq is a 3.5 feature, the framework is required to be that version.
A good way to determine would be to change the target framework to 2.0 and see if it builds.

Code compiled against 3.0 or 3.5 may run on the 2.0 framework, but only if you do not use any libraries that are specific to the 3.0+ framework. One good way to find what's causing your code to fail is to switch your target to 2.0 and change things so that it compiles. Since one of your target installations is .NET 2.0, you are going to have to write .NET 2.0 code; this is not unique to .NET. In the past, writing an application that executed in both Win95 and WinNT involved extra work for the developer to carefully make sure the appropriate API was used.
Technically, 3.5-targetted code can run on 2.0 with no problems, but there's some gotchas you have to watch for. If anything accesses something that is unavailable in .NET 2.0, that will fail. This doesn't happen when the application starts, it happens when the application tries to make the call. I tested this by making a console application that does a little bit of output, then tries to display a WPF window. The output is made, but the application throws an exception when it tries to display the window on a machine with nothing but .NET 2.0.
Another gotcha is that VS 2008 actually comes with the .NET Framework 2.0 SP1, and there are a few types and methods in SP1 that are not in the normal 2.0 Framework. Visual Studio will not flag these methods as unsafe.
Finally, if this is a web application, the default web.config file for 3.5-targeted projects is very different than the web.config file for 2.0-targeted projects. Make sure you're distributing a compatible web.config. This is likely the problem you are encountering. A cheap workaround might be to change your target to .NET 2.0, copy that web.config, and use it in this case. Keep in mind that if you are using any 3.0+-specific language features or types your code will still fail, but this should get you past the web.config.

You're not going to be able to run code targetted to 3.5 on the server unless you get 3.5 installed on it.
The problem isn't your code, rather that the required libraries will be missing.

This is not possible. Although the CLR has not changed (like it did between v1.1 and v2.0) The libraries have. You cannot run a 3.5 app that doesn't have the 3.5 fraework installed. All of the Linq features are made possible by the 3.5 framework.

One error is in Web.Config. The published Web.Config is setup to allow compilation from .NET 3.5, which is the reason it includes build provider information.
Beyond that, your code won't run. By using LINQ, you're referencing assemblies that don't exist in .NET 2.0.

I was just going to leave a comment by my rep is not quite there. I agree with the crowd so far and believe that lassevk's answer is the best so please give him the rep for that. One this I wanted you to know about though is that once you install 3.5 on your IIS server (6 or better). When you go to the IIS Manager and right click on your website to access the ASP.Net tab. You will see AFTER the install of the 3.5 Framework that there is no 3.5 option available. It will still show it as 2.0.50727. Don't worry about that, it will still work just fine. Because of this inconsistence (thanks Microsoft) some confusion has been caused. Actually I think this is why you may have thought that 2.0 would run your 3.5 code just fine. Hope this helps and anyone please edit this so it makes more sense.

You can may use of some C# 3 features whilst targeting .NET 2.0. Its the language features which by the time its compilied to IL will run on the 2.0 CLR regardless of whether that CLR is part of a 2.0 or higher framework install.
Hence you can use anonymous types, extension methods and Lambda expressions but as soon as you do things like LINQ you then need external libraries that are part of 3.5
If you are only doing LINQ to Object you could add the LINQBridge to your distribution.
Another problem you can run into is if you are shipping a web application that includes the source code, such as code behind files, in line code and .cs in the App_Code folder.
You can end up shipping C# source code which compiles on the developement machine with C# 3 compilier present but fails to compile on a server only equiped with C# 2. In this case you can't use any new language features either.
What's worse is that specifing the .NET 2.0 framework as the target in the Visual Studio doesn't stop you using C# 3 language features. You get no warnings that such syntax will not compile on a 2.0 machine.
Hence if you are shipping such a web app, you'll need to compile pretty much everything first.

You can just copy over the 3.5 dlls onto the server. You can absolutely run 3.5 code on a 2.0 server.