I have an application deployed via ClickOnce, along with a separate .NET console application that needs access to the ClickOnce application's installation directory. By the application's installation directory, I mean:
"C:\Documents and Settings\[username]\Local Settings\Apps\2.0\[obfuscated folder]\[obfuscated folder]\[obfuscated folder]\application.exe"
, or on Windows 7:
"C:\Users\[username]\AppData\Local\Apps\2.0\[obfuscated folder]\[obfuscated folder]\[obfuscated folder]\application.exe"
Is there any way for me to generate, or preferably determine at build time, what the obfuscated folder names will be for my application?
Basically, I would like for the console application, which is built and distributed with each release of the application, to know the directory structure under which the application will be installed.
I know that I can determine this location from within the ClickOnce application using "Application.ExecutablePath", and then save the value to a known location, but I would much rather be able to predict the application's installation path in advance...
Any ideas?
I don't think its possible to know that path in advance. It can also change when you update the version of an app too.
Do you want to know the path so that the two apps can find each other? If so you could use a simple IP listener in one app and connect to it from the other one. You can just connect on 127.0.0.1 and then ask the other app the path.
Related
Is there a way to set the ClickOnce client installation folder to something static like "...\%User%\Appdata\Local\%MyProgram%?
Detailed info:
I am using ClickOnce to distribute an intranet application. Everything works fine, and the application installs and updates like it should. The one issue I am running into is one of the modules in the application moves files from one folder to another folder. The end user has Trend Micro installed, and the application was getting nuked and quarantined every time the module ran. I had the IT department whitelist the application, but due to the random installation path below "...\AppData\Local\Apps\2.0...", and because Trend Micro can't handle the '.' in 2.0, they were having to whitelist the executable below the "\Local\Apps\" folder, which they weren't comfortable doing. Is there a way to change the ClickOnce installation folder to something like "...\%User%\Appdata\Local\%MyProgram%?
Simple answer: no you cannot change that path, it is a key part of the sandboxing that is a feature of ClickOnce.
Even with custom manipulation and re-signing of the ClickOnce manifests you cannot alter that path (this is one of the ways that ClickOnce allows you to have multiple published instances installed on your machine even if they are the same version).
I'd suggest that before packaging (i.e. as part of your release build process) you sign your binaries with a code signing certificate from Verisign or similar - anti virus products typically use this as an indicator of whether something can be trusted. If that fails to solve the problem then look at whether you can whitelist based on the file name rather than the file path.
I have an app and I am working on the installer for it. Assuming that I want the installation to not require elevation and I want the application itself to never require elevation and I want the updater for the application (which is build in) to never require elevation where should I install the application to?
Caveats:
This application is not signed.
I am okay if each user has to install it separately under their profile.
Can I use the registry in the install and accomplish the same goal?
The only writes it makes are to setttings/configuration files.
.NET 4 app.
A common choice is the local appdata folder returned by SHGetFolderPath(CSIDL_LOCAL_APPDATA) (Win2K and later) or SHGetKnownFolderPath(FOLDERID_LocalAppData) (Vista and later).
This returned path is something like:
"C:\Users\arx\AppData\Local" (Vista and later)
"C:\Documents and Settings\arx\Local Settings\Application Data" (pre-Vista)
It's normal to create company name and application folders under here, so you'll finish up with a path like:
"C:\Users\arx\AppData\Local\BlahSoft\BlahApplication"
Update
If you want this path from .Net you need Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
Your question is tagged both WIX and .NET; the two have different syntaxes for known-folder paths. The .NET command to get the current user application folder is Environment.GetFolderPath(Environment.SpecialFolder.Programs).
If you want to install to a WIX path, it has predefined properties for each known folder; [ProgramFilesFolder] is to the 32-bit application folder and [ProgramFiles64Folder] is to the 64-bit folder.
We have an application that was built for the Windows Mobile and Windows platforms, using Visual Studio 2005. We have both versions of this application developed using a single code base to try and reduce code duplication. One of the issues that we encountered with this was that the ConfigurationManager was not available for the Windows Mobile platform. We worked around this by building our own ConfigurationManager that reads and writes settings to the "Application.exe.config" file in the Program Files folder. So both our Windows version and our Windows Mobile version use this same custom ConfigurationManager.
This worked fine on Windows XP and Windows Server 2003, but on Windows 7 we have encountered a problem and I don't know how to work around it. When we make a change to the config file (which we can only do by copying it to another folder, changing it and then copying it back... otherwise we get an "access denied" message when we try to save our changes directly in the Program Files folder), the change that we make is only reflected if we run the application as Administrator. If we run the application as a normal user, the default setting from the install are always shown. We suspect that this is a Windows 7 security-related issue, but can someone explain why this is happening? How can we change the settings so that they are also applied when the application is run as an ordinary user?
Windows 7 requires elevated privileges for several folders, including program files. It's not good practice to try to work around this.
Since you are using a custom solution, one option is placing your configuration file under %APPDATA%\yourproduct, which can be reached with
var appDataFolder = Path.Combine(Environment.SpecialFolder.ApplicationData, product);
A better solution is probably to use different configuration managers for different platforms, though. Couldn't some kind of abstract factory be applied?
I suspect your app tried to write to the config file at least once running non elevated and without a manifest. This made a "compatibility files" folder for your config file. When you run non elevated it looks there now. (See http://www.gregcons.com/KateBlog/FindingFilesYoureSureYouWrote.aspx for screenshots of how you can confirm this.)
If all you want is for a human, or some utility program you wrote that can run elevated, to be able to edit the config file, you can leave it where it is and put a manifest on your app to prevent virtualization. See http://www.gregcons.com/KateBlog/AddingAManifestToAVistaApplication.aspx for a sample manifest. That blog post goes on to tell you how to embed the manifest, but you don't need to, an external manifest will work. If your app is foo.exe, name the manifest foo.exe.manifest and put it in the same folder. This will prevent virtualization and cause the app to read the "real" config file.
If changing the config file will be a normal everyday occurrence, don't write the file under Program Files. AppData is a good choice.
I have created a windows application setup program, it needs to have a text file in the application folder. The file is also included while creating the setup.
Once the setup successfully completes and my program tries to modify the file based on user input, its simple throwing an exception.
I am using Windows 7 Home Premium OS.
Any suggestion/help will be great to overcome this issue.
This is normal on a Vista or Win7 machine. Or a properly secured XP machine for that matter. The normal install location for programs, like c:\program files\your company\your app, is read only for most users. UAC is a counter-measure to malware messing with programs.
You'll need to store the text file into a writable location, the AppData folder. In the Setup project, right-click "File system on target machine" and select User's Application Data Folder. Find that file back at runtime through Environment.GetFolderPath, passing Environment.SpecialFolder.ApplicationData. Or use "User's Personal Data Folder" if the user should be able to find it back easily through the Documents folder.
What exception is being thrown? It could be a UAC issue.
I have a simple C# console application developed on my local machine using VS2008 Pro. I want to know how to deploy this solution onto a network share folder?
A similar Java console program is already placed (as a JAR file) in the same network share folder. Users simply open command prompt, navigate to shared folder and type "java -jar programName.jar inputParameter1 inputParameter2"
How can I achieve the same with .NET?
You can copy the exe over yourself, go to the bin folder in the directory your source code is in and copy it there.
or you can click the BUILD menu and use the PUBLISH menu item. This will allow you to enter the path to your network share and visual studio will copy the built app to the folder for you.
If your application is really "simple", you should be able to just copy the files to a shared folder and run it from there. However, if your "simple" application tries to do things that are restricted by the permissions you might have to configure them with caspol. Assemblies loaded from a shared drive have much fewer permissions than the ones loaded from a local drive.
It would be mostly the same process as the Java program. To deploy, compile the program and copy the exe from the bin folder (along with any dependencies) to the network share.
To run the program users would open the command prompt, navigate to shared folder, and type "programName.exe inputParameter1 inputParameter2"
You can use Publish feature of VS. Note that you can change settings in the Publish section of the console application project to remove some features that you don't need. For instance the renaming of .dll and .exe files by appending the '.deploy' extension to the name of the files or publishing in a new 'version' folder each time. Go to "Project Properties"->"Publish" and remove "Automatically increment revision" checkbox at "Publish Version", click "Options..." button and clear all checkboxes there too.
Right click your project, select publish which will make an executable, you can put that in your shared drive, similarly users can go into the command prompt and run it and give some args.
In the exact same way assuming they have the proper dependencies installed (.net, 3rd party assemblies, etc). copy the bin folder then have them execute the exe file.
Take a look at ClickOnce deployment:
ClickOnce is a Microsoft technology
for deploying Windows Forms or Windows
Presentation Foundation-based
software, also called Smart clients.
It is similar to Java Web Start for
the Java Platform.
MSDN
Wikipedia