I have finished a Windows C# application and this is the first time I am going to deploy it. I have searched for many tutorials. The microsoft site tells me to use the ClickOnce method. I have also tried from the Publishing settings. After I double click and install the application successfully, once I try to open it, nothing happens!
I have left all the settings as they are in debugging stage (e.g. Configuration: Debug) and all the other publish settings are left as they are.. can some one be kind enough to provide me with a dummy tutorial as I don't have any clue where to start from. I am saving some data in a file in DEBUG/Data. What will happen to this file?
Don't use the "deploying option" that Microsoft's offer. because its rubbish.
I'd suggest you to do it your self, here is what I suggest:
Protect your source-code with obfuscation.
Compile your application with the release mode (F6) not the debug mode (F5).
Copy your compiled files from "Release" Folder.
Download any Freeware Installer such as "Inno Setup".
Pack your files with the installer.
Distribute your application.
you can also skip the installer part. all you need is to distribute it as a Zip file or Rar.
there are plenty of other steps can be involved depending on how heavy your application is.
Related
I upload an app on google play store. I am using xamarin / visual studio and I have bundle my app. so this is aab, not apk. also I am using visual studio so I dont have gradle file
it is giving me 2 warnings
Warning-1
This App Bundle contains Java/Kotlin code, which might be obfuscated. We recommend you upload a deobfuscation file to make your crashes and ANRs easier to analyze and debug. Learn More
Warning-2
This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug. Learn More
My Question: how do i create deobfuscation & symbol files? are these just empty text files?
On Google Play store console - I found a section where I can upload mapping & symbol files, but not deobfuscation file
App Bundle Explorer > Downloads > Assets >
Re-Trace mapping file > upload
Native Debug Symbols > upload
For this, you can refer to document Preparing an Application for Release.
You can follow the following steps to build the app for release:
Specify the Application Icon – Each Xamarin.Android application should have an application icon specified. Although not technically necessary, some markets, such as Google Play, require it.
Version the Application – This step involves initializing or updating the versioning information. This is important for future application updates and to ensure that the users are aware of which version of the application they have installed.
Shrink the APK – The size of the final APK can be substantially reduced by using the Xamarin.Android linker on the managed code and ProGuard on the Java bytecode.
Protect the Application – Prevent users or attackers from debugging, tampering, or reverse engineering the application by disabling debugging, obfuscating the managed code, adding anti-debug and anti-tamper, and using native compilation.
Set Packaging Properties – Packaging properties control the creation of the Android application package (APK). This step optimizes the APK, protects its assets, and modularizes the packaging as needed. Additionally, you can provide your users with an Android App Bundle that's optimized for their devices.
Compile – This step compiles the code and assets to verify that it builds in Release mode.
Archive for Publishing – This step builds the app and places it in an archive for signing and publishing.
Especially part Shrink the APK and Protect the Application.
Pay attention to Application Protection with Dotfuscator:
Even with debugging disabled, it is still possible for attackers to re-package an application, adding or removing configuration options or permissions. This allows them to reverse-engineer, debug, or tamper with the application. Dotfuscator Community Edition (CE) can be used to obfuscate managed code and inject runtime security state detection code into a Xamarin.Android app at build time to detect and respond if the app is running on a rooted device.
Dotfuscator CE is included with Visual Studio . To use Dotfuscator, click Tools > PreEmptive Protection - Dotfuscator.
To configure Dotfuscator CE, please see Using Dotfuscator Community Edition with Xamarin. Once it is configured, Dotfuscator CE will automatically protect each build that is created.
I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).
I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.
Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?
We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.
It would be useful to know more about your application and how you are doing the upgrade because:
You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.
Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.
Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.
So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:
a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.
b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.
This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.
I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.
If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).
REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.
msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress
If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).
It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.
Log: I would try to create a good log file for the install, to determine what is going on:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).
Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.
The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
The Advanced Installer guys have a very nice, technical article about this:
How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.
According to below link
https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup
"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."
Now I have a completed program, that needs to be deployed with some files. I would like to ask, if it is possible to deploy the program without the use of ClickOnce or other external tools, with the minimum amount of required files?
The program will run on a server, and will be updated locally, but since the program is installed per user, does that mean if I log in to the server with my user, a person that uses the direct path to the program will not find it? It also makes maintaining the program slightly more annoying, because when changes come, the current maintainer will have to always navigate to the xyz folder to edit one config file. How do I publish the program without ClickOnce or other tools?
Your options include:
Click once (which you don't want)
Visual Studio installer Projects
WiX Toolset
Other installers ...
Write an installer on your own (wouldn't recommend)
Just put the exe (and other needed files) in some directory and launch the program
Put the exe on a shared location and launch from there
You can redistribute as a set of files. However I would not recommend this approach. You force the person who deploys your program :
Choose location for the files
Remember this location when time to uninstall comes.
Handle updates and version management
Restore program functionality if any of the required files will get damaged.
You can use VS Setup project template, here's tutorial
Alternatively you can use free Wix installer, it has a bit of a learning curve but provides much more power to the developer.
You can do perMachine install both with VS setup project and with wix.
I'm a web developer building my first production grade console application (C# .NET 4.0). I have a question about creating a settings file that the user can edit before running the console app (to customize output folder paths, etc).
I'm a little confused -- when I publish my console application and install it (by clicking on on the generated setup.exe file in my target publish folder), all I get is an entry to my start menu. Nothing gets installed to C:\Windows\Programs, and there doesn't seem to be anywhere else on my system that files get installed to. Essentially, I'm just trying to find the app.config xml file so that I can edit it after the program has been installed. (btw, when I click on the start menu entry, the program executes properly).
Is what I'm trying to do possible?
For a clickonce deployment, the files will be installed under the profile of the user who installed the application (by default).
For windows XP this should be:
C:\Documents and Settings\username\LocalSettings\Apps...
For Windows 7 (and Vista?) this should be:
C:\users\username\AppData\Local\Apps...
An installation program for your software is a separate piece of software.
You can definitely make one but when you compile your console app it doesn't create an installation executable. It just makes it's own executable. You can copy that executable alone and run it. If you need more resources to go along with it and therefore decide you want an installation program, you have lots of options.
The two that spring to mind in this case though, are setting your project to use "ClickOnce" from the project properties, or adding a "Setup and Deployment" project to your solution from the "Other project types" section of the add project dialog box.
I've wrapped up version 1 of my desktop application and it's ready for deployment.
Just to test things out, I grabbed the contents of the /debug folder and copies that into a folder of the target machine and the application works.
I'm sure this is not the correct way to do this.
I've created a Visual Studio Installer project and created that as well. My question is, do I have to set something similar to ASP.Net's debug=false, when deploying an application?
Thanks for the suggestions.
There are several deployment options of .NET applications. Your approach is often called "xcopy deployment" and is a simple copy of all included files.
Typically you don't copy the content from the debug folder. Instead you change the "Solutions Configuration" combo in Visual Studio from debug to release, compile the application and copy the files from the "Release" folder instead.
When creating a release build of your application the compiler applies more optimizations to the code to create a more efficient executable.
There are other methods of deployment. Here are some that creates different kinds of installers
ClickOnce (Right click on your project in solution explorer and choose "Publish")
Installer project (creates an MSI installer)
WiX (creates MSI installers too, is more cumbersome than an installer project, but more flexible
etc.
The benefit of creating an installer is that it is usually simpler for an end user to run an installer than it is to copy a loose bunch of files. An installer can automatically create an icon on the start menu, make sure the correct version of .NET framework is installed etc.
If you only want to run your application on one or at most a few computers it is probably not worth the extra work of creating an installer.
I would do the following when creating a "release candidate" of your app:
Create a branch or tag in your source control repository identifying a particular build as the source of the release candidate. A branch is nice because it allows you to make changes necessary to release the source that you don't want in your dev environment.
Set up the Release build configuration of your app. Among other things, yes, this does ensure the DEBUG compile constant is not set, so anything that is conditionally compiled based on that constant will not be. Default behavior is also to optimize the code (faster runtime, not debuggable) and to not generate PDBs.
Build the installer. Ideally, the output of the installer should go somewhere else than the main output of the primary project.
Run the installer (doing so from its build location is fine). It should execute with no errors, and produce what you expect.
"Smoke test" the application as installed. Basically, run through some basic operations that do not modify the data layer it works against, that will verify there are no major problems with the app possibly caused by a missing DLL or incorrect connection strings/app settings.
Copy the installer to a thumb drive of sufficient size, and try the same installation and smoke test on a "virgin" computer that does not have VS installed. Ideally, it should mimic the environment of the target machines as closely as possible.
For one, you shouldn't be deploying the Debug assmeblies. You should build in Release mode. http://msdn.microsoft.com/en-us/library/wx0123s5.aspx
I've never used the Installer projects, but I tend to stay more towards web and console stuff. Hopefully someone else will have a more detailed post :)
Use a Setup and Deployment project. This way your application will make sure user's have required libraries. It will also download the required .net version if it is not installed.
And always release the "release" version and not the debug version. Copy/Paste from debug folder will not work in call the cases and its not the right way to release an application.
Also, if you don't want someone reverse engineering your code, you might want to use Dotfuscate.