Help! The folder C:\ProgramData\Microsoft\Crypto\SystemKeys is growing out of control. It is doing this on some of our servers and some desktops. We are a medium to small business and use Active Directory (not Azure AD). I've heard that this folder is used by IIS, SQL Server, Remote Desktop Licence Server (maybe other things too?). My guess is it has something to do with Remote Desktop as I've not seen this problem with any computer that hasn't been using Remote Desktop. I've heard that some of the keys in this folder are important so you can't just delete it. Anyone have any idea what to do to get it to stop, what causes it, or how to clean it up?
Here my file properties:
Thank you for any help.
I found an answer to this question. Turns out in my case it was because of an application writing to this directory. Contacted them and they are implementing a fix in the next release (October 2021). In the mean time, I've deleted the extra keys in the folder. So far no issues.
So we made a rookie mistake, One of our project team members had forgotten to commit for a couple of weeks, (some of which were vacation) but then when he did commit he did something wrong, most of the code he wrote has been overwritten with what was on the server after trying to resolve all the conflicts automatically.
So is there any way to get the code he used to have on his PC back? because a lot of work has been lost and we can't really afford to make it all again.
So just to clarify, the code which is lost is not on the server, it were his uncommitted changes on his client machine.
We are using the team foundation server and visual studio
Take a look at folder:
C:\Users\%USERNAME%\AppData\Local\Temp\TFSTemp\
In my case, searching by method name, i can recover a mistake merge =)
Nope. Code lost that never made it into source is lost. This is one of the biggest selling points of distributed version control like Git.
If your using Windows 7 or similar check for previous version of the file on his/her computer, right click the file options should be their
If you have not compiled after doing the merge, you can use DotPeek by JetBrains to decompile the assembly and get your code back
I have exactly the same site settings in coda 1.7.4 as I do in coda 2 but when I click the publish arrow in coda 2 it tells me "Set both local and Remote paths in a site to publish your changes".
I have already done that but it still is not working. As I said the same settings are in the older version and it works fine and publishes.
Anyone have any of the same problems.
I contacted Coda support for exactly this issue today... Same as you, after setting up a site with the correct remote and local roots - confirmed because I could connect to both - but still the publish window said "Set both local and Remote paths in a site to publish your changes".
Literally the solution was to close Coda down and re-open it. Apparently this is a known issue, when setting up a new site you have to restart Coda to use the publish functionality.
Just by closing Coda and restarting it the publish function now works for me.
I had this problem and none of the above worked. I got the following reply from the team at Coda and it worked a treat.
Right click the saved site in question and choose Edit. Disable publishing and automatic indexing.
Save and close the site
Open the site, then from the menubar choose File > Sites > Rebuild Site Index
After the indexing competes, restart Coda and then re-enable publishing (and optionally, automatic indexing)
I had the same issue until I ticked the "Use Publishing" in the site settings.
Check out the image: CODA 2 Site Settings
I can now publish via the ⌥⌘P on a Mac.
I hope this helps.
Specifically, you have to close all the open documents in Coda, reconfirm the local and remote directories configured for the site, then close Coda2 and reopen it.
Honestly, that a bug like this still exists, is amazing. After all these years, I still need to keep Dreamweaver around. Get with it Coda! #coda #coda2
My "fix" (this time) was:
to edit the FTP server's domain to be not working,
open the site,
let it complain the server is wrong,
close Coda,
reopen Coda,
fix FTP domain,
open site,
and voilà!
A classic I-learn-by-complaining case. ;-)
(Coda 2.6.10...)
I had a situation where the publishing had been working ok, and then mysteriously stopped.
I tried all the suggestions previously answered by BenLeah, Ben Darlington, Robert Barrueco, and Manu, and upgraded to the latest version of Coda2 (from 2.6.9 to 2.6.10), but none of these restored publishing.
What did finally work for me, was to physically delete the site connection panel in Coda2 and create a new site altogether (with the exact same settings). Not sure if this will work again if the publishing turns itself off again in the future, or if it solves the problem for anybody else. If it ever does, I'll update this answer.
It's unbelievable that Panic has not fixed this by now.
Finding and deleting every Coda related file and reinstalling Coda did not help.
My "fix" (this time) was to delete the site in Coda and recreate it.
Publish stopped working for one of my sites, but for entirely different reasons than others have discussed here. I used Time Machine to roll back to a recent version of the site, renaming the original folder so I would know not to use it. Coda 2, however, kept pointing to the original (renamed) folder.
So it seems Coda uses a unique ID to identify the local root folder, not a simple file path. This is probably a good idea in most cases—it means if you move or change the name of this folder in the Finder, Coda still knows where it is. But if the actual folder changes (as it will if you recover from a backup), you can expect the unexpected.
I still don't know why the publish feature stopped working with the renamed folder. (In some ways I'm glad it did, as it stopped me publishing from the wrong folder.) All I know is that updating the 'Local Root' of the site fixed the problem.
You have to set the FTP putting the mouse on the file between your site and the page. Below the menu, as soon as you click file you will open in the middle a screen. Then you put in your FTP settings.
I see it all of the time when installing updates to retail applications, but after searching for two days, I have not found a way to do it. I am trying to create a package with InstallShield LE in VS 2012. One of my customer requests is to warn the user when the program being updated is running, and allow them to close the app (or possibly have the install try to close it). Is there any way to do this (the simpler the better)? Thanks in advance for your help!
This should just happen. However you may need to make sure that you didn't remove the file and re-add it to your installation; instead make sure you update it at the source location and rebuild. (This helps ensure that the underlying component settings remain the same, which may be relevant to Windows Installer's Files-In-Use detection.)
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.