I have a VB6 app that I've been selling for over 12 years. Sometimes I have users that have a hard time getting the app to run. The data writes are going into /My Documents so nothing but the installation files (EXE, etc.) are going into C:\Program Files (or C:\Program Files (x86)).
The fix to their problem is to start the app, even though it appears hung, then show the task manager, view processes, right-click my app's process and uncheck UAC Virtualization. Then I have them repair the installation and all is fine.
Why is my process getting put under UAC Virtualization and how do I prevent this from occuring? I also use InstallShield 2010 Professional to create the installation, I'm not sure if it's related to the installer or the app itself.
To prevent virtualization, add a manifest to the application. Whether you say asInvoker or requireAdministrator, you won't get virtualization any more. I am guessing asInvoker will be better for you since the app works fine without elevating.
You can just put foo.exe.manifest in the same folder as the exe, or embed it, which has some tricky stuff like making the manifest a multiple of 4 bytes long. This question covers some gory details of embedding.
Related
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
Bear with a bit me before jumping straight to the normal caching fix solutions. Here's what happening:
I have a project, a single project out of dozens in our solution that appears to be refusing to update its code when I build and run. It's not part of the xap, but a dll sitting along side the xap.
Things I've already determined not a solution:
I've checked the output of its dll and it has been built, and its contents updated to match my code, verified with dotPeek. But it refuses to display the updated code.
I clean, rebuild the solution, and restart the dev server but it refuses to display the updated code.
I switch to a different browser, no dice.
I clear browser cache's to no avail.
I completely delete my local code and do a fresh fetch from our repository, again, no love from silverlight.
I have not been without a little success though. The ONE bone I've been thrown was over the weekend. Not touching it for a couple days, I came back to work on Monday and, without having done anything to it, it just updated. Now, however, it's cached again, or something, because it's stuck in the last set of changes I made to it.
So my question is this: What am I missing?
Most likely your files may be read only and MS Build fails to display error message and it does not update files. In case if you have mistakenly checked in your .xap files, then this is possible, you will have to remove it from your source control and also make .xap file writable by removing readonly checkbox.
Visual Studio checks in your .xap files by mistake and silverlight build does not report any error.
Second, do you have any other file backup service installed like Shadow copy or Dropbox kind of online backup service, something is probably making xap files readonly and that is causing this problem.
Here there are couple answers: Prevent Silverlight 3 from caching while debugging
Code below helped me(add this to Page_Load of page that hosted the app ):
Response.Cache.SetExpires(DateTime.Now.AddSeconds(-100));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
UPDATE:
Prevent Silverlight xap from being cached by proxy server
"So my question is this: What am I missing?"
An internal caching mechanism that our application uses. So, none of you could really have helped me as it was an architectural feature of our software.
I am in the process of writing an offline-capable smartclient that will have syncing capability back to the main backend when a connection can be made. As a side note, I considered the Microsoft Sync Framework but since I'm really only going one-way I didn't feel it would buy me enough to justify it.
The question I have is related to SQLite vs. SQLCE and ClickOnce deployments. I've dealt with SQLite before (impressive little tool) and I've dealt with ClickOnce, but never together. If I setup an installer for my app via ClickOnce, how do I ensure during upgrades the local database doesn't get wiped out? Is it possible to upgrade the database (table structure, etc. if necessary) as part of the installer? Or is it better to use SQLCE for something like this? I definitely don't want to go the route of installing SQL Express or anything as the overhead would be far too high for what I am doing.
I can't speak about SQLLite, having never deployed it, but I do have some info about SQLCE.
First, you don't have to deploy it as a prerequisite. You can just include the dll's in your project. You can check this article which explains how. This gives you finite control over what version is being used, and you don't have to deal with installing it per se.
Second, I don't recommend that you deploy the database as a data file and let ClickOnce manage it. When you change that file, ClickOnce will publish it again and put it in the data directory. Then it will take the previous one and put it in the \pre subfolder, and if you have no code to handle that, your user will lose his data. So if you open the database file to look at the table structure, you might be unpleasantly surprised to get a phone call from your user about the data being gone.
If you need to retain the data between updates, I recommend you move the database to the [LocalApplicationData] folder the first time the application runs, and reference it there. Then if you need to do any updates to the structure, you can do them programmatically and control when they happen. This article explains how to do this and why.
The other advantage to putting the data in LocalApplicationData is that if the user has a problem and has to uninstall and reinstall the application, his data is retained.
Regardless of the embedded database you choose your database file (.sqlite or .sdf) will be a part of your project so you will be able to use "Build Action" and "Copy to Output Directory" properties of that file to control what happens with the file during the install/update.
If you choose "Do not copy" it will not copy the database file and if you choose "Copy if newer" it will only copy if you have a new version of your database file.
You will need to experiment a little but by using these two properties you can have full control of how and when your database file is deployed/updated...
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
I need to learn more about creating setup projects from within Visual Studio to support the following scenario:
When the user starts the setup, he needs to choose between the parts that he wants to set up. The setup should offer to install three web services, one web site and maybe even run some SQL scripts to install/update the database.
During installation, the user will need to tell where he wants the sites/services to be installed within IIS. He also needs to specify the database connection which is used within the services/sites and to update the database. And there will probably be a few other wishes too. It should also support an uninstall of the site and services, but the database can continue to exist.
Is this even possible with the Setup projects that Visual Studio creates? If not, no worries. I don't need an alternative solution! I just need to know if this is possible before trying myself and discovering it's not possible after weeks of trying... This is for an internal project and I want to make life easier for the administrators who need to install/upgrade these sites/ services every time when there's an update. (About once every two weeks.)
Stay well away from vdproj stuff and move to WiX ASAP (As you'll see me being advised in questions I asked here). For a start, flexibility around where to put the IIS apps is seriously limited (you get one virtual dir and the user can only choose the name, you cant have multiple instances).
The other side of this is of course that the vdproj stuff is an 80% solution. Ultimately you can add as many custom steps as you like, and they can pop up dialogs and whatever they like. There's no reason why a custom step cant do all the things you want.
I just know that I once thought like you, and looking back wish someone had grabbed me by the scruff of the neck and said, just use the proper stuff - even if it seems a little harder initially. There is a conversion tool that will suck in your vdproj and spit you out a WiX.
By all means, try wizarding up what you need and seeing if it works - most of the stuff is pretty searchable - just know when to call it quits.