I want my program in Visual C# to allow the user to generate a portable .exe file to be run on another user's computer, with the portabe .exe receiving the values the first user inserted. I don`t want to use a configuration file or any other file to store the input values to be then read because I want the .exe to be a single file. I have the main and the second program (future portable executable)
as different projects on the same solution. Is there a way to modify values of the portable .exe or does a new program needs to be compiled on the fly?
To formally answer the question.
You can convert the assembly to IL, search and replace and recompile. However, if you are building this application, you should really consider the need and use case for such very thoroughly.
If you need just to modify the behavior of an application, you have a plethora of options.
Registry (can be remotely done)
A config file (though you ruled this out)
You could use a login method to a resouce
Wcf for instance
Active Directory
A network DB
Rebuild you app for these users
Msbuild with a batch file to tweak something
A pre build script
If you are really tricky you "might" be able to track down the offset of an int and tweak it. However this seems very unreliable
Or if you really have your heart set on this, see the following and associated questions
Modify Emdeded String in C# compiled exe
Is it possible to Add/Remove/Change an embedded resource in .NET DLL?
Update from Ben Voigt Comments
Win32 Resources can be changed after being embedded in an EXE. .NET
System.Resources can only be changed before embedding. C# applications
are compatible with both kinds, but the distinction is very important
The The necessary function is UpdateResource
You can typically append to an .exe without breaking it and then read the data in upon execution.
See: appending data to an exe
Related
I've run into some issues with the Visual Studio Properties.Settings.Default method of saving config values persistently in a user.config file in AppData. The main problem is the way the file is stored - it's location (and the file contents) when running unit tests compared to the main executable. It also changes along with the assembly version.
Update:
To clarify (per comments), when running the app different ways (and from different projects in a solution), the Properties.Settings.Default auto-generated functionality uses a different folder to store the user.config file in each case:
When running the application directly (with the company name in the assembly information empty):
[Documents]\AppData\[MyApp]\[MyApp.Exe]_Url_[hash]\1.0.0.0\user.config
When running the Resharper test runner:
[Documents]\AppData\JetBrains\[MyUnitTestProjectName]_StrongName_[hash]\109.0.0.0\user.config
When running the xunit test runner within Visual Studio:
[Documents]\AppData\Microsoft_Corporation\[MyUnitTestProjectName]_StrongName_[hash]\15.0.26720.2\user.config
Since the user.config file is stored and looked for in different places, depending on whether I'm running the app directly or running unit tests, when I save info out of my normal running exe, I cannot access that same info while running unit tests.
Similarly, if I switch from a GUI frontend to a Console frontend, I have the same issue, because the file is specific to the run-time executable parent (I think). I just want a single config that is saved and used for any part of a given solution that wants to access it.
So, is there another built-in way to do configuration management in .NET, or another way to solve this issue?
I see lots of applications that have custom named config files and other data in their AppData folders - are they using a standard .NET library for that?
I finished my app and now I want to create a update system. I have the installer so I can install the application in other machines, it was made with InnoSetup (I don't know if it is the best way, but it worked). I know the basics, I have to compare the current version with a string stored in a in a web server, if it is greater, download the files. Now, what files? Because the InnoSetup gives me these files:
Where are the .xaml (design) files? And the .cs files? Are they compressed in the .exe? For example If I add a few lines to a class, I want to download this class, no the full installer again. Because the final size of my application is 30Mb, if I change some things of a class, I do not want the user to have to download the 30Mb again
In the most basic of terms, when you compile your program the compiler turns your cs and xaml files into machine readable code and puts it all into an exe file.
Yes, if you add a few lines to a class and recompile it, it will rebuild your exe (assuming the class is part of it, and not an external library).
You still have dependency dll files that you need to include, and any other external content that you've included. But once you have all the external files installed, you wouldn't theoretically need to download them again on an update. Only the files that you've updated, ie the exe.
I have students in high school who have created some programs using Visual Studio C#. They created some games and would like to now upload them to the web. I am pretty new to Visual Studio C#. I thought after a program was "built" that you could go into the bin/debug folder and get the exe file for the program and be able to play the game without having to have Visual Studio on the actual computer you are playing it on. It works with some of their games but some of them, there are graphical files that are missing in the exe file if all the other files aren't stored in the same place. How can I get a clean exe of their game? Can that exe be loaded up onto a web server so they can play it from there or at least download it from there?
Microsoft wrote a guide on how to do exactly this. It's on their MSDN website, which is sort of like the developer back-bone for a lot of Microsoft software and documentation.
Old guide: Adding and Editing Resources (Visual C#)
Newer guide: How to: Add or Remove Resources
The gist is that the program needs to know where the files are, relative to the location of the compiled binary (in this case, an .EXE); There's several different ways to do this, depending on your level of expertise. I would suggest that you take a look at the guides above to start that journey.
there's a few ways of doing this. (Also, make sure you're creating a 'release' build when you compile).
You can include resources in your game by creating a resources file. This is something I usually do only on winforms applications etc.
If you have on-disk files you need to distribute those on-disk files along side your game. You could do this by zipping up your game.exe and the /files/images.img folder (or what ever your resources content folder is named).
If you're feeling adventurous you could create a 'deployment project' which is a project that allows you to create an installer file. This is a bit more work however you will have fine grained control over what files go where etc.
Good luck!
EXE files generally aren't self contained for video games with many resources, just add resources in an external folder and make sure the paths to the resources in their games are not absolute but relative in the local directory.
So for example:
get rid of paths like C:/Users/Bob/Desktop/Game/Images/player.png and replace with /Images/Player.png.
Also, an EXE generally doesn't run client side on webpages, it is possible but difficult. Things such as Flash are made for this sort of issue. I'd say make the webpage a place where they can download their games. Github has a nice way to do free websites called gh-pages. OFC, you could host one yourself but that would require a lot of setup work.
Like Monza said, you can zip up the files for download. Or, you could create an installer if you wanted to be really ambitious.
I thought after a program was "built" that you could go into the bin/debug folder and get the exe file for the program and be able to play the game without having to have Visual Studio on the actual computer you are playing it on.
That is correct, given that the other machine has the necessary .NET framework version installed AND any other resources like .dll files and config files are also present. When the application is ready for release, you can set the Build options in the project properties to Release, and then when you build all the files needed for distribution will be in the bin\Release folder.
It works with some of their games but some of them, there are graphical files that are missing in the exe file if all the other files aren't stored in the same place.
This may depend on how the application was written. If resources like pictures are embedded in the assembly then those files will not be needed to run on another machine. If the application is using hard coded paths for the image resources in the source code, then the application will likely break if the necessary files aren't present when the .exe is executed.
Can that exe be loaded up onto a web server so they can play it from there or at least download it from there?
Yes - you could upload the .exe to a file server to make available for a download, but you would not be able to run it within a browser over the web. I would recommend zipping up the .exe and other files needed and hosting the .zip file on the web server for download; browsers may give a warning or block downloading an .exe .
Hope this explains it a little bit for you.
I am new to C#. I am an admin, not a programmer, but I am starting to see how being able to write some console apps could help me with automation. So I wrote one and it works well.
Here is the issue. Every time I execute the exe file for the console application, it generates a .config file. There isn't really anything in the config file. just a few lines. How do I make it stop. The Program.cs is really just calling SCOM's SDK to put a machine into maintenance mode.
Developed in: c# in visual studio 2013
.net version used - 3.5
It's not entirely clear what you're asking. But assuming commenter Jon's guess is correct, and that you really mean that when you build your executable, a .config file is generated, then his advice is correct: just remove the "App.config" file from your project, and no .config file will be generated. The "App.config" file is the template for the .config file; at build time, the file is copied to the output directly, using the executable name and the extension .config.
Please note that this may or may not be safe to do. It probably is. However, some C# projects have configuration information in the .config file that is actually needed. Please see Is app.config required in .Net 4.0 C# projects? for more details on that question.
Finally, I will suggest that for simple automation tasks, you may find other tools more appropriate that even a simple C# console program. The two I use most commonly are PowerShell and plain old batch files, though there are a number of other similar scripting-style automation tools that work on Windows (including a variety of *nix-style shells that are compiled for Windows).
We have an application that we wish to install just a basic shell for. As the users use it, it will download and install the necessary dlls for actions that need to take place (imagine a wizard application scenario with several possible paths). Currently, everything is installed for all possible paths through the shell app.
For about 3 months out of the year, the dlls used for the possible paths go through a high churn rate with updates, so we wish to start ensuring the users have the most recent version of these dlls. The idea is that after all their selections are made, we'd make a web check to see what dlls are required for their selection and check to make sure they have the most recent version of those files.
All of this we have a plan for on how to do it. The problem I'm fighting is what is the most appropriate way to "install" these files. ClickOnce is not an option...too much legacy stuff here. Our app is installed in "Program Files" which obviously has restrictions for writing random files into the program's install folder under Vista and later.
Right now I see the options as the following:
On install mark the install directory as writable for the "Everyone" group. I haven't actually tested to see if this would work yet, or if Vista does something different in this scenario.
Split the download portion out into a second app that we can have prompt for elevated privileges so that it can download and install these files.
I'm leaning towards the second option since that maintains the security aspect of the Program Files folder. Others in the group lean towards the first option because they just don't want to have to worry about things. Or is there some other option I'm missing?
The app is a .NET app, though it has some requirements of third party dlls that are not managed assemblies.
As long as the dlls you want to load are managed, there are several ways to do this.
One way is to designate an Environment.SpecialFolder path such as AppData and dynamically load assemblies into your appdomain from there. RssBandit does this for plugins, there is a special directory that loads dlls and searches for specific interface implementations, loads them into a temporary appdomain, and then calls them from the app. You could take this one step further by using an IoC library like ninject or structuremap.
you could also try MEF, the new extensibility framework coming out in C# 4.
Personally, I like what Firefox/xul apps do. It's a hybrid of your two proposed solutions, I suppose. They have an updater.exe that lives in the install directory. I assume that means that the install directory is made writable during install so that they can run the update application. However, having never deployed a application in this manner, I can't tell you how much of a headache (or not) it is.
An alternative which you haven't mentioned, and may not know about, is using the .Net download cache. When you attempt to load an assembly you can give it a code base to load from. If you set the codebase to a web url (i.e. http://mywebhost/mycoolapp/) .Net will download the assembly from that url if it's not found in the download cache. It will also grab the latest version of the assembly from the web url if there is one.
This approach can be a pain as you'll likely have to deal with CAS security issues if your app needs elevated permissions. However, it is nice not having to write code to download the latest versions of your assemblies for you. If you want more information, I can find some resources and give more detailed examples.
The way I handle it is to have an update.exe installed into program files next to the main .exe file.
Then, on app startup, I have the app download an xml file off of the web and save it in the App Data folder. This file contains the latest versions of the dlls and has a simple Filename, Version structure.
Run through the list of filenames and if you don't have the dll locally or you have an older version, then add the needed dll to an update list.
After you generate your update list. Fire off the Updater.exe with a command line list of the files to be updated. You don't have to write them to program files but I do. On Vista, my updater pops up the UAC prompt correctly (as it should to maintain Program Files' security).
The updater then downloads the files to Program Files and restarts the main app.
One problem with firing off the second app is that you have to give it a manifest with "AsAdministrator" set in it.
This isn't hard to do, but once the updater is done and retriggers the main app, it cannot start the main app with normal privileges. An exe running as administrator can only start other exe's as administrator also, even if "AsInvoker" is set in the manifest. I don't know why you can't restrict it back to normal rights...you can only elevate permissions for some reason...