I have made a few setup projects in my time, but this is a first for using User Settings. I may be using the wrong "words" when searching since I cannot be the only person with this issue.
The user settings I am talking about, are the settings you define in the Project Properties -> Settings. They work like a charm inside VS, but when I make the installer (using the free setup project extension, not the WiseInstaller LE that is included) and run the EXE, nothing takes.
I tried including the settings.settings file, and the App.Config file but that idea did not work.
What am I doing wrong? If I need to convert these to registry entries, then I need to do a lot of recoding. These are scoped to User, not Application.
Thanks,
Dave
I figured it out, it had nothing to do with the setup project, but rather my code flow. The settings form first tried to connect to the DB, since the connection information is entered on that form, it threw a cannot find error, so thinking that is what it should do, I hit continue. Well I was a bit wrong.
That error kind of made the form stop working since the information comes after the DB connection. I added a trap, and changed the code flow and all is good again.
Thanks
Dave
Related
I have one project, which I’ll call “Working”, because it works fine, and all login/etc. works fine.
I copied the “serverless.yml” file and changed everything appropriate to start a new project, which I’ll call “Puzzling”.
On the “Puzzling” project, I can log in just fine, but when I refresh the browser, I’m logged out again. So I cannot do things like (e.g.) change a user’s password.
I have all the Cognito configuration in a “config.json” file, with all the right settings.
In fact, if I copy just the “Puzzling” config.json file over to the “Working” project, then the “Working” project stops working properly! So I don’t think it’s my code.
I’ve compared the two “serverless.yml” files carefully… I don’t see anything different.
Any clues VERY MUCH appreciated… Thanks!
Fixed: Rebuilt the project by copying from "Working".
POSSIBLY:
One difference is that "Working" allows users to sign themselves up, and "Puzzling" did not.
Another thing is that when I went to delete the server code, it failed, saying that the database (or another resource, I forget exactly) was owned by another project. I deleted that project through the AWS Cloud-formation UI (which only partly worked...).
(And thanks #NewUser, but it's really a lot of code.)
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.
I've added a couple of lines to a file, let's say it builds to be foo.dll. It's part of more then one dll file, but it's the core dll. What I did was that I added a couple of lines so it should add some log data to the database. It should not affect any other files what so ever.
So i tried to deploy it. We don't have the magical one click deploy, we are just copying the right files to the right place.
So now, since i have a change in foo.dll, i thought for myself that i just could copy foo.dll and the server would be happy.
I was wrong. Browsing the website i now get "Generic Errors", dont know what that is. I've also tried to copy all the new dll files (4 i total) but that did not solve the problem either.
The error it gives are
Http Error 404.0 not found
Module: ISS Web Core
Notification: MapRequestHandler
Handler: Static File
Error Code: 0x80070002
replacing the new foo.dll with the old one solves the problem. and i've tried to restart the webserver. :-(
I asume you have "published" and not just "compiled" your Web?
You also need to take care off the "Solution Configurations": Debug and Release.
In a normal publish process you would change the configuration to release and publish your project into another folder.
After you have done that you just need to collect the desired files and upload them.
Keep in mind that you need the newest version of you web project. Maybe there are some changes online that your local project hasn'T. This would cause such problems.
We don't have the magical one click deploy
Why not? It's not magic, and it's pretty easy to set up. Get any continuous integration software (I would recommend BuildMaster since I am a developer for it and it's free now) and you'll never have this problem again.
I'm having a problem where the Entity Framework edmx file is apparently losing its relationship to the connection string that it was built with.
The designer for my .edmx file was working perfectly - I could do "Update from database" and it would always jump to the wizard step that would allow me to add tables, procs, etc. Now when I click "Update from database", I get the "Choose your data connection" wizard step where it wants me to select a new database - if I go through these steps, it will create a new connection string for me, and regenerate all of the objects as if I was starting from scratch.
The contents of my app.config file are exactly as they were prior to the problem, but I did modify the file, then revert it back the way it was. I'm thinking somehow modifying this file triggers something that causes me to lose the binding, but I can't figure out what that is.
The connection string key in the config file matches the CdmEntityContainer attribute in the EDMX file.
I've even tried killing my codebase and re-checking-out from source control, but that doesn't seem to work. Other people working on the same codebase are having this same problem, so it seems that there's something definitely wrong somewhere in the project. But there were no relevant changes to the .csproj or .sln files - just nothing I can see anywhere that could be causing this.
Any ideas? The only solution I'm seeing right now is to delete and recreate the edmx files from scratch, but I'm definitely hoping to find something better.
EDIT: If I generate a brand new edmx in the project, unrelated to any of the existing ones, it seems to fix the rest. It must "reset" whatever is funky in the project. But this can't be a legitimate solution, so I'm still hoping for something better.
I just had this issue and in my connection string I was missing
application name=EntityFramework in the data Source
I just had this and solved it.
The problem was that the edmx was being used as my DAL, with its own project and web config, and the DAL was called by my ASP.NET project (the solution's default project) with ITS own web config.
The configs had been the same for ages, but the ASP.NET project was pointed to another server (ie the connection string changed). Even though the DAL's connection string was still unchanged, valid and the ASP.NET project wasn't involved when you want to "Update model from database" at design time, it must be something to do with the default project clashing with it.
I changed the connstring in the web config of the project containing the edmx to be the same as the default project's one, and it worked again.
If you happen to be bouncing between environments (e.g. dev, prod) when this problem popped up and you are running different SQL Server version (e.g. 2005, 2008) in those environments, you can have some problems. The DB version number gets stored somewhere in the .edmx file.
If that is the case, let me know and I can dig up the specifics and respond with them. If not, I don't know what it could be.
Good luck!
EDIT: I realize this probably has nothing to do with the actual problem, but I wanted to provide the specifics I mentioned in case someone else runs across this. The ProviderManifestToken attribute in the Schema element (inside the .edmx) contains the database version number. Note that it actually uses the year (e.g. 2005, 2008) instead of the true DB version number. If you create a model on one version and move it to another version, you'll need to manually edit the file to change this value.
<edmx:Edmx Version="2.0" xmlns:edmx="http://schemas.microsoft.com/ado/2008/10/edmx">
<!-- EF Runtime content -->
<edmx:Runtime>
<!-- SSDL content -->
<edmx:StorageModels>
<Schema Namespace="..." Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2005" xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="http://schemas.microsoft.com/ado/2009/02/edm/ssdl">
...
</Schema>
</edmx:StorageModels>
</edmx:Runtime>
</edmx:Edmx>
Old question but I thought I would post the fix that worked for me for those who still have this problem. In my case, it was simply a password issue. I was working in test, but the connection string was using the password for production. A more helpful response by VS might be to display an "Invalid login or password" type of message since that was actually the problem.