• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

question on microsoft's .net programing

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

ndnsoulja

Registered
Joined
Aug 8, 2002
hello, im kinda new to this programing and we're learning gui right now. and we are using microsoft .net complier. when i start my project i make it as a windows form application. after i'm through with my programing at stuff i want to be able send the application to my friends so they can use it. for example: we're building a calculator and i want to send it to a friend so he can use it (not the program) but the finished product the actual gui calculator. i thought i could send thim the "calculator.exe" from the debug file but he says that didn't work. so any help will be appreciated. thanks.
 
Any program written in .NET depends on the common language runtime (CLR). The program you wrote is not in itself native code (that can be run on its own), it's in intermediate code that needs the .NET runtime environment to run it.

So your friend needs to go to windows update and get the .NET runtime (also called the CLR).


EDIT: I wanted to add that anything written in .NET languages C#, VB.net, c++.net, j# needs the CLR. These are called managed languages because they require the runtime to execute. If you wrote something through MFC C++, which is unmanaged, you wouldn't need the runtime... you would need the MFC dll though.:p
 
Last edited:
To add to what mccoyn said, if he downloads it as a redistributable, make sure he gets the service pack (either through windows update or the link below). It fixes a lot of bugs.

.Net Framework 1.1 Service Pack 1

Oh and by the way if you're using visual studio.net 2003 another way to do this is through a deployment project. First you need to install the bootstrapper located here:

Visual Studio.Net 2003 Bootstrapper Plugin

Then Right-click on your solution and say "New Project..." Go to other and select deployment project. You then add your project output to the deployment project. When you build the solution you'll get a Microsoft installer project that will install your program and the .Net Framework if they don't have it automatically! Let me know if you want to go this route and you need help. The deployment projects have a pretty low learning curve though and I'm sure you'll be alright!
 
Last edited:
Good tips Fugue, that should do it.

If that didn't clear up the problem, post back what error you're getting ndnsoulja and we'll see if we can figure it out.

Brian
 
thanks for all ur help. i got the bootstraper and but i don't know where to right click and stuff. like u said on the solutions..but i don't really know where that is. sorry im pretty new to this. but i really appreciate all the help thanks again.
 
wait will this bootstraper, let the program be on its on and allow it to work w/out getting having .net?
 
No it won't run on its own. Anything written in a .Net language needs the .net runtime installed. Think of it this way, a C# program is not really a program at all. It can't manipulate anything... it doesn't have any drivers to listen to your keyboard or even write to your screen. But the .net framework does. So what your program does is it "lives" inside the .net framework (much like java applications "live" in the java virtual machine) and tells the .net framework what to do. It's kind of confusing at first!

In the same way that you have a windows.forms project in your solution you can also create a deployment project (File menu->New Project...->Setup and Deployment Projects). This project can be set up to make an installer for your app. Normally when this installer (the one created by your deployment project) detects that the .Net framework isn't installed on the user's machine it will alert the user that they need to go get the framework. With the bootstrapper plugin it will also include the .Net redistributable (the one you can download from mccoyn's link above) for you (along with your app) and automatically install it if it's not there already! That might be out of scope of what you want here... I'm not sure. But if your friend downloads the redistributable and installs it he'll be able to run your program. (Just be sure to also give him the link to the service pack! ;))

I'm sorry if I was confusing there. Let me know which route you want to go and I'll be happy to help! :)

EDIT: I'll try to make some screenshots tonight of how to include a deployment project for you (the operative word being try ;))
 
Last edited:
Realistically you may want to simply send a link to the user if the application is in development:

http://www.microsoft.com/downloads/...E3-F589-4842-8157-034D1E7CF3A3&displaylang=en

Creating an installer that will install .NET is a good idea for finishing touches (and also a good way to work with creating installation packages) but, if you're emailing small exe's and the like, it may be a bit much given the effort/size of the installer...

Brian
 
How to add a deployment project

Ok So here's a visual walkthrough of how to add a deployment project to your solution. I've already installed the bootstrapper plugin...

This is a C# Windows.Forms simple calculator project called "WindowsTestApp". The solution is also called "WindowsTestApp".

image 1

I then right click on the solution icon...

image 2

... and select Add->New Project...

image 3

The "Add New Project" Dialog appears. I then select the "Setup and Deployment Projects" folder on the left and the Setup Project template on the right. Go ahead and name the project what you want and put the location where you want it created. I left it the default: "Setup1".

image 4

You can see that the Setup1 deployment project has been created and the File System Page is brought up by default. This is a representation of the File system where the application will be installed. Application Folder is wherever they decide to install the app. I then right-clicked the Application folder...

image 5

...and selected "Add->Project Output..."

image 6

In the "Select Project Output Group" dialog, I selected my project from the dropdown and then selected "primary output" from the select box. I pressed Ok to dismiss the dialog.

image 7

Notice that the output has been added. Also noticed the highlighted Merge Module. This the dependency to the dotnet framework that will, thanks to the bootstrapper, be installed.

image 8

Next I went to the Build menu and selected "Configuration Manager...". I wanted to build this in release, so I made sure both projects were checked for release.

image 9
image 10

Finally, I went once again to the "Build" menu and selected Rebuild Solution (this built first my executable and then the installer package)

image 11

Now to test my installer! I went to the folder where the Setup1 project lives. I then opened the Release folder. There are my setup files!

image 12

I then doubleclick setup.exe and install my program!

NOTE: If the machine I ran the setup files on didn't have the .Net framework installed, at this point I would have been prompted to install it first (and thanks to the bootstrapper it could install it for me). Also note that ALL of these files are required to install my app.

image 13

EDIT: I think Brian is right... so use this for your reference in learning about Deployment projects. Enjoy!
 
Fugue said:
Anything written in a .Net language needs the .net runtime installed.
I used to think that until I read about a product called XenoCode. Not that its anywhere close to free.

XenoCode said:
.NET Framework embedding: XenoCode 2005 allows the .NET Framework libraries to be embedded into the output assembly, dramatically reducing the complexity of application testing, deployment, and support. XenoCode 2005 automatically identifies and statically binds a minimal set of Framework dependencies, reducing overall deployment size and eliminating dynamic link costs.
 
Wow I'll have to file that in the "learn something new everyday" category. Thanks mccoyn!

I wonder about the usefulness of that though... what's your take on it? It seems like a managed language that is pretty much turned into something other. That you could end up having more bloat doing it that way because all the shared assemblies that you reference would become private. So if you couldn't get enough of windows.forms executables couldn't you have redundant code bloating past the size of the .Net runtime? Plus it seems like you would lose other goodies from not having the runtime (side by side assembly execution, have all of your existing applications benefit from a single update to the framework/GAC, etc.) and that your architecture would be turning C++ like (update to the framework means all executables would have to be recompiled)... well C++ like with statically linked libraries, of course. Which would make me want to keep that cash in my pocket and use C++. :) Anyway, just curious about your thoughts on it.

Well that "aside" aside ;) Just wanted to say that I'm always glad when you post mccoyn. You always have something knowledgable to say!
 
The .net framework is not that large (29 megs). When longhorn comes out it will be integrated into the OS so no one with Windows will know the difference. Most of the things you do with WinForms can be done with WebForms so end users would not need the runtime, just the server.
 
Fugue said:
I wonder about the usefulness of that though... what's your take on it? It seems like a managed language that is pretty much turned into something other. That you could end up having more bloat doing it that way because all the shared assemblies that you reference would become private. So if you couldn't get enough of windows.forms executables couldn't you have redundant code bloating past the size of the .Net runtime? Plus it seems like you would lose other goodies from not having the runtime (side by side assembly execution, have all of your existing applications benefit from a single update to the framework/GAC, etc.) and that your architecture would be turning C++ like (update to the framework means all executables would have to be recompiled)... well C++ like with statically linked libraries, of course. Which would make me want to keep that cash in my pocket and use C++. :) Anyway, just curious about your thoughts on it.
The main goal of embedded runtimes is to avoid the classic DLL hell problems. What if I inadvertantly depend on a bug in .Net 1.1 which gets fixed in 2.0? Or worse, they change the implementation slightly in a way that doesn't effect most people but ruins my application? Suddenly installing a program which installs .Net 2.0 mysteriously ruins mine. I'm not so sure how nicely XenoCode's embedded runtime plays with the system's runtime and other assemblies. That could be a big breaking point.
 
No Problem ndnsoulja!:)
Did you end up making a deployment project, or did you just send the redistributable?

I can see your point mccoyn... but isn't that the idea side by side assembly execution? That you can target a specific version of the assembly and, if you wish, continue to use that version and require it(since a user can have multiple versions of the same framework installed on their machines due to strongly typed assemblies)?

But then again as Oswald Avery once said:

"It's a lot of fun to blow bubbles, but its wiser to prick them yourself before someone else tries to".

And one inherent "bubble" is the Service Pack. You have to trust that this will not change the implementation in way to burn you. So yeah... there always seems to be pros and cons. Side by Side execution should solve DLL hell for most versioning issues... but not the service pack (as far as I know).
 
Back