I am trying to deploy an application using ClickOnce. The problem is, I am saving user generated files in the application's working directory. Now when the user installs the next version of the application, his old files will no longer be available to him. What is the best workaround for this problem - or does this mean I have to roll my own installer!
thanks!
Look into using isolated storage rather than the application's working directory.
This post should help you out.
When Windows Vista came out and developers could no longer store data in Program Files, Microsoft recommended using LocalApplicationData. We store a lot of cached data there, under a folder with our application's name. I wrote a blog entry showing exactly how to do this if you're interested. I call it Where do I put my data to keep it safe from ClickOnce updates?
Related
Yes, I know vb6 ancient and all that. It's still an interesting question. and the issue might not even be with vb6....
Background: We have a server running a vb6 application for our users who access this via Citrix. This installed application accesses its DLLs (also written in vb6) from a "shared folders" location.
What I want to do is have the previous version of this same app on the same server, accessing it's own set of (previous versions) DLLs. I am half way successful. the renamed app in another directory runs. But it crashes immediately upon using any feature that draws from the DLL's code.
Apparently the registered DLLs of the current version are being called upon. I dont want that. I want the DLLs found in the same directory as the renamed older app to be called upon.
Can that happen in a windows server? is this an installer's settings issue? Have you ever had this situation before? were you successful?
thanks in advance.
Harry
Post Script:
The bosses decided that experimenting with the DLLs and system settings was a waste of my time and not worth the risk. So they're throwing money at it and another server will come online for the sole reason of providing the previous version to the citrix users who want it. Thank you to all of you who pitched in with great tips and leads to other posts. (yeah I'm sort of disappointed too. Kind of wanted to know what the solution was to this.....)
The OS should be looking for the dll’s in the following places and order
The directories listed in the App Path registry key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp
Paths) if any
The directory where the executable module for the current process is located
The current directory
The Windows system directory
The Windows directory
The directories listed in the PATH environment variable
Given that you are using a shared folder for your dll’s, I would suppose that the app is setting the current directory to your shared folder OR is using the PATH environmental variable to specify where to look. I don’t think it is using the app path registry key path because that is version specific and you said you are using a different version.
I would suggest your try setting the path via HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
Some background to my problem...
We are currently using ClickOnce to deploy part of our solution which was working a treat until we encountered a scenario where we are now required to have multiple instances of our application installed on the same PC. We are able to achieve this internally and have this working perfectly as we know what instances we have so our build process will update AssemblyName to include the instance name before publishing the installer, this means we are able to have multiple instances on our PCs internally (ie, test, live and demo etc).
Our external deployment process is slightly different, we take one of the ClickOnce installers created in our build (along with all our other components that make up our application) and as the ClickOnce installer is deployed on a server we update the app.config along with the manifest files and resign so they now have client specific details. If a client chooses to have multiple instances of our product installed the ClickOnce will now fail when a second instance is installed on a desktop PC as all instances share the same assemble name.
So finally to the question, does anyone know of a way to update the manifest etc after the clickonce package has been created to allow multiple instances to be installed? We could go down the route of building many clickOnce installers but I dont think this will really work for us, is there perhaps an alternative to ClickOnce which provides a similar upgrade experience for non-admin users?
Hopefully someone will be able to share their experiences and help me resolve this.
Thanks in advance
Doug
I don't know of another technology that allows such a simple auto update process. So sticking with ClickOnce... I think this link might be useful. It explains what you need to do to have the same app installed twice. Essentially changing the assembly name and product name should do it.
Hope that helps.
Greg
I'm using the MVC Code First approach to create a SQL Compact database (from WebConfig: data source=|DataDirectory|MailBoxDB.sdf). The .sdf file should get created automatically, and it does if I manually create the App_Data folder on the web server (Windows Server 2008). However, I'm trying to automate the deployment process and I want to eliminate this manual step. I'm using MSDeploy to create the deployment package. Is it a permissions issue that prevents IIS (7.5) from creating the App_Data folder on its own? If so, which settings should I be focusing on? Any ideas?
I had a similar scenario (generally more complex, although without a database in App_Data). I pieced together several SO questions and found a solution which I've posted on my question on the same topic. Take a look at my answer and hopefully it helps.
we've recently stumbled across the excellent Dispatch for ASP FTP deployment plug in. It looks great apart from one thing: It doesn't work with Visual Studio 2010, at least for us, anyway. (It's supposed to work fine.)
(Yes, we've tried everything: We've managed to get Dispatch working for another FTP site, but not the main one we regularly deploy to. We have managed to connect to our main site through FileZilla FTP, so the site itself is configured correctly. All settings have been triple checked, but the software still throws up weird errors (always to do with its internal libraries).)
So does anyone know of any other comparable FTP-based, deployment plug-in for Visual Studio?
Here's what Dispatch does (and so any suggested replacement must do):
Monitor any altered files
in the project. When a file is
changed, it's added to a list of
files to be deployed.
To deploy these
files to the live site, all we need
to do is click "Upload" and the plugin will
connect via FTP to our live site and
upload the selected files.
We can filter out
any filenames we don't want to be
monitored/uploaded (e.g. .cs or
web.config or /Images/, etc.)
I think that's all the features that we need. Thanks for any suggestions!
Note: If you're wondering why we need such a service, it's because we deploy many site changes over the course of a single day. Publishing the entire project to a folder, zipping it up, then FTPing that zip file, only to have to unzip it, and then install the entire project into the live wwwroot takes far too long. With Dispatch you're able to upload individual files in a single click.
After much back and forth between me and the creator of Dispatch, we managed to narrow down the problem to the library he was using (Rebex FTP). I posted a question about the issue on the Rebex forums, and it was revealed that their software might have a bug with IIS7.5. They suggested a quick hack/fix, which I tested and discovered worked.
Mr. Dispatch then quickly implemented this hack/fix into his software, and lo! I had a fully working copy of Dispatch... So no need for a replacement any more!
(And from what I've seen, there isn't even any other plug-ins offering this functionality, so it's just as well.)
Just an update - Dispatch does not work with VS 2013 so if you have VS 2012 with Dispatch installed, Keep it. Also the website is gone so it looks like all development has ceased. I have been using Dispatch since VS2005 and it has been great for just sending single files up when I need to. Too bad it is gone.
I built a very simple one for myself - you right click the file in Solution Explorer and it then uploads that file based on a settings file you create.
It's super crude but it works and the source is there to make it better if you like -
https://github.com/garazy/vs-2017-ftp-upload
Big enhancements have been added to VS2008, VS2010, VS2012. Below is the article. I found that Microsoft did all the above while I was searching. Since this came up high in what I was searching, thought should share this knowledge.
Deploy a Web Application Project Using One-Click Publish Without Web Deploy
So I am continuing testing and releasing changes to my app and I have come across a pain point that I am unsure how to deal with.
First off, my app uses a SQL Server CE database to store information and I need to be able to make changes to this db so I've created an internally updating process that runs whenever the application runs to make sure the db is up to date.
The crux of this internal update process is another SDF file named DBUpdates.sdf that contains all of the db schema changes that need to be applied.
The problem I am having is that the MSI distribution I created will not overwrite this file. It appears that when SQL Server CE opens this file, it changes the Modified date/time of the file. This is a flag to the MSI process that the file has changed, and that it shouldn't overwrite the file. Well now I am seeing that my db changes aren't being applied, because the MSI process thinks the user has changed this file.
At this point I am kind of stumped. I was planning on using an MSI distribution but maybe I can't. What do you think?
What about storing your .sdf as an embedded resource in your executable, and then extracting it to a temporary location on disk (as necessary) and perform the updates.
Unversioned files with MSI can be a bit difficult to handle if you need to force the installation of the file. You can see this previous question, for some ideas, How to add a version number to an Access file in a .msi.
The question contains a link to this blog post, http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx, which suggests the way I prefer to deal with this problem. Add the .sdf file to be part of your executable's component. The downside to this is if someone delete the .sdf file, but not your executable I don't think a repair of the application will catch this. If your using Visual Studio to create your MSI files then this may prove a difficult solution to implement. I strongly suggest your check out WIX in that case. It is a better MSI build system.