clickonce

What I would like to know is the definite approach to encrypting connection strings in a config file. Here are my questions: Using machine-level encryption, can't anybody accessing my server write a little .Net program to read the contents of the connection strings? If I am deploying my application to users machines in an enterprise environment, and the application has connection strings in a config file, how can I make sure only my application can decrypt it? The scenario is especially interesting in a ClickOnce deployment scenario. I've read about people storing the config unencrypted at the

So I was writing an application that requires access to the registry. I had not touched any build settings, wanting to get the thing working before I added the other touches, such as a description or name. Out of the blue, I get an error that will not go away. ClickOnce does not support the request execution level 'requireAdministrator'. Now, I hadn't touched ClickOnce in this application. All I had done was include a manifest file requesting these permissions. My problem now is that this error will not go away, and I cannot compile my program. Any advice on what to do? (Side note: I am about

Is there a way (hacky will do) to allow a user to go back to a previous version of a ClickOnce network deployed application? I've looked in the docs and API and there seems to be no way. You can selectively choose if you would like to update, but once updated there is, seemingly, no way back. ClickOnce will use whatever version you send them. If you send them an old version, they will rollback to that old version. Back in May my buddy David wrote an article on how to do this on a per-user basis. We can literally have every user on a different version. The application even tells the database

I keep on running across this error when trying to deploy via ClickOnce File, image.jpg, has a different computed hash than specified in manifest. I realize that this is an error that has a lot of google results but I have been unable to resolve this. The stranger part is that this ClickOnce package has been deployed on a variety of other machines (at least 30) without any issues - this is only happening on one specific machine with Windows 7 and x64. On the one hand, I have checked the manifest file and the version numbers don't match as they should and I've heard that this can be the cause

When you install a ClickOnce application, the program runs after the install. Is it possible to install without running? I know I can use a setup and deployment project and create an installer, but I'd prefer to use ClickOnce. I guess you could fake it. Introduce an "IsInstalled" boolean property, defaulted to false. Then in Program.cs, change your Main() method to look like this: [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); if (!Properties.Settings.Default.IsInstalled) { Properties.Settings.Default.IsInstalled = true;

I created a VSTO Outlook Addin that uses a library Html2Xhtml.dll (.NET) which calls another Html2xhtml.exe by executing System.Diagnostic.Process.Start(). However, it fails to call Html2xhtml.exe (i think) because the working directory even when launched from Visual Studio is the current user My Documents folder. I have no control over the code in Html2Xhtml.dll so I cannot use absolute path; but I suppose I can change the working directory of the Add-in at runtime. However, If I install this via ClickOnce or some other means where I do not know the install path the user is going to choose,

I'm developing an application which is to be deployed with ClickOnce. After downgrading from .NET 4.5 to .NET 4.0 and replacing repairing bad references, now I have problem with deployment package. Some files, most importantly System.Net.Http.dll are not deployed with the application. I've done some checks but can't conclude why exactly this happens. My suspicion is that package is created with expectation that this assembly already exists on target machine. This would be reasonable if target framework was .NET 4.5, but not now that it's .NET 4. Strangely, System.Net.Http.Extensions.dll gets