I have a IReliableDictionary. Every time I remove the application and deploy it again, I expect that all the data will be erased.
But it looks like something persists on disk and the dictionary is able to load this data after redeploy. So when I try to AddAsync something after redeploy I get the ArgumentException with additional information key. Looks like I'm trying to insert already inserted key.
The name of the dictionary is the same and the whole cluster isn't redeployed, only application itself.
Is it a normal behavior? Because I can't insert a new value after redeploy and it seems logically incorrect.
Local dev cluster, SF version 2.1.163.
Make sure you're using the right deploy mode in Visual Studio. It has two ways to deploy applications locally:
Auto Upgrade
Remove
Remove will remove an application completely, removing all state, and then redeploy a new application.
Auto Upgrade will perform a rolling upgrade so that you don't lose state. This is handy when you're working on an application that needs to be loaded up with data to test it, so you don't lose all your test data every time you make a code change and run the application.
Right click on your application project and go to properties to set this:
Related
I have a database project in Visual Studio 2017. Our database project is managed just like any other library of code where multiple developers can update the project as necessary. To ease the pain of deployments, I have built a custom deployment task in our TFS 2018 (vNext) Build process that is a powershell script that calls sqlPackage.exe. SqlPackage compares our compiled database project (*.dacpac file) to our target database (in Dev, QA, etc.). I have the custom step configured so that it will write the expected changes to disk so I have a record of what was changed, then sqlPackage runs a second pass to apply the changes to the intended target database.
My DBA enabled the Query Store in our SQL 2016 Database. During my sqlPackage deployment, one of the initial steps is to turn the query store off, this makes my DBA unhappy. He wants the ability to compare pre and post deployment changes but if the query store gets turned off, we lose the history.
I have tried several of the switches in the documentation (https://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx#Publish%20Parameters,%20Properties,%20and%20SQLCMD%20Variables) but I can't seem to find the magic parameter.
How do I stop SqlPackage from turning off the query store?
My current script:
sqlPackage.exe /Action:Script /SourceFile: myPath\MyDatabaseName.dacpac" /OutputPath:"myPath\TheseAreMyChangesThatWillBeApplied.sql" /TargetConnectionString:"Integrated Security=true;server=MyServer;database=MyDatabase;" /p:DropObjectsNotInSource=false /p:DropPermissionsNotInSource=false /p:DropRoleMembersNotInSource=false /p:BlockOnPossibleDataLoss=True /Variables:"CrossDatabaseRefs=CrossDatabaseRefs
Is there a better way? I am surprised that I had to write a custom TFS Build Task to do this. Which makes me think that I might be doing it the hard way. (But this has worked pretty well for me for the last several years). I love database projects, I love that they enforce references and ensure that we don't break other objects when a column is dropped (for instance).
Any insight would be greatly appreciated.
Either disable the scripting of database properties using /p:ScriptDatabaseOptions=false, or update the database properties in the project to reflect the desired Query Store settings.
To set the Query Store settings in the project, right-click the database project in Solution Explorer and open Properties. From there, in the Project Settings tab find the "Database Settings..." button. In the Database Settings dialog, click the Operational tab and scroll down to find the Query Store settings.
Apparently, all we needed to do was add a post deployment script to re-enable the Query Store. Hope this helps someone out there...
USE Master
ALTER DATABASE [MyDbName] SET QUERY_STORE = ON
I have an issue in updating contents in Umbraco. Whenever I update something in Umbraco, I have to wait at least one hour, sometimes 12 hours to see the changes at front-end.
The only way to see the changes immediately at front-end is "empty the connection string value umbracoDbDSN and refresh the page, then put the connection string back and refresh the page". I have to do everything I update something in CMS.
Do you guys have any idea what is happening here? Thanks.
The problem was. Umbraco was configured to run on load balanced servers on our old servers. I had to turn it off on the new server.
<distributedCall enable="false"> in umbracoSettings.config
What version are you running? When v5 first came out, I had a big problem with that (and solved it like you by touching the web.config to force a reset. Hopefully you are not using v5 (as its been discontinued and has extreme performance issues).
I have not had that problem in any v4.x versions that I can remember; changes should show up instantly after you republish.
Are you running in a standard configuration? Using a webfarm by anyt chance?
Is the ~/App_Data/umbraco.config file being written to on publish? This is the XML cache file that is used in displaying you website.
When you publish a node, the data is serialized into XML, stored in a database table and then written out to the umbraco.config cache.
This could be some kind of permissions issue, if umbraco doesn't have rights to read/write the file. Or you could have a corrupt dll that just isn't writing to it correctly. Or perhaps it's writing it out just fine, but your server is caching you pages in a weird way. Either way, I'd take a look first at the umbraco.config and make sure the data is being written to it on publish.
I was doing a small project and everytime I run the program, I can feel more lag and delay, until it is completely not working anymore.
I checked with the task managers and found many "Javaw.exe" Instances. Then I opened the debug field and realize that it runs a new instance everytime I run the same project.
here is the link to image of the instances in debug area.
http://i50.tinypic.com/2hz4spu.png
The temporary solution for me is to terminate them from the debug area. Is there any way to prevent the same project from creating a new instance everytime it is run ? I only need one instance that can be reused everytime I run again and again.
Thanks for any response in advance.
No, I'm sure that's not what you want. If you restart an application, it's probably that you want to test some changes you've just made in the code. So Eclipse needs to start a new instance of your application. You could also want to start two instances of an app because they need to talk to each other.
If you want previously launched applications to stop, then stop them. Your app seems to be a GUI app. Use the close button on the main frame of the app to close it. As simple as that.
It's often not desired to kill an application, because it might need to properly close resources, or tell the server it's leaving before exiting, or whatever. Having Eclipse kill apps without a conscious request from the user would not be wise.
I'm working on an update for an already existing iphone app. The existing version contains a .sql database file which is used in the app.
I would like to use a new version of this file in the update of the app. On the first startup of the existing app the .sql file is placed in the caches directory of the users iphone. From what I can understand from Apple's documentation the files in the caches directory might get copied from the old app to the new versions caches directory when the user updates the app.
Does this mean that for being sure my new file is used in the updated version I should use a different name of the file?
And what happens with the old file? Do I have to manually delete it from inside the app? Which means I have to check if it's there at every startup of the app?
Thanks
Michael
Yes, you could use a different name, or you could use the same name, and do an "upgrade" (delete and replace) on the first time the user uses a new version.
This does imply checking at every app start, but that's not a bad idea anyways. Having some code that checks versioning at app start lets you put any data upgrade stuff in one place.
One technique is to use NSUserDefaults to keep around two pieces of information: the originally installed version of the app, and the most recently run version of the app. You check these at startup. If they're not there, write both of them. If the most-recent version is lower than the running app version, run your upgrades and bump the version. You could use the first flag to know conditionally in other places whether to expect certain data to be sitting around or not. Having versioning stored explicitly lets you know which version you're upgrading from, too, which might not be obvious if the user hasn't downloaded say 5 intervening updates.
Ok, I have a ClickOnce app that I'm testing and I ask the user for a couple of pieces of information the first time they use load the app; Customer Id and Name. I then set the Properties so that they'll be saved across sessions. The property is Properties.Settings.Default["Customer ID"] and similar for name.
So I uninstall the application through control panel and reinstall the application but the settings are still there! I go and find all directories for my application and delete out the settings but the application acts like it still has them. I can even step through the debugger and see that they are still there.
How do I get rid of them all? This is very frustrating since it makes it almost impossible to test new data and to debug any first time installs.
Thanks...
I believe the user config values are stored in this location:
%APPDATA%\<AppName>\<AppName><AppConfigName_GUID>\<AssemblyVersion>\user.config
Have you checked there?
ok, in case anyone has the same problem in the future. I had set the properties in Visual Studio through the Settings.settings editor. I removed them and everything was normal again...
In answer to the general problem of removing settings when the program is reinstalled, you could add unique piece of data as well, such as the date of the executable, its checksum, or something similar.
Then check that against the saved data when you program starts. If they don't match, it's a reinstall and you can delete the stored data.