We are using a SymStore on a fileshare and I recently noticed, that there are over 100k transaction files in the 000admin folder. About 95 % of these files have an .deleted extension, because they have been already deleted.
So is it safe to delete those files to save some space and make life easier for NTFS?
TLDR: no, in general it is not safe to delete these files.
Long answer: SymStore can do different operations, main of which are "add" and "delete". On every operation it changes files in 000Admin folder, adding there information about what was added or what was deleted. Later this information can be used by other SymStore commands, like "symstore query" command, for example. If you delete some of the transaction files from 000Admin folder - it means history of commands will not be accurate anymore and "symstore query" can't work properly.
Of course, if you are 100% sure you don't use such commands and you just need to store pdb files - you can delete files in 000Admin. However, you should understand some functionality of SymStore will not be available to you anymore.
I have created one Usecase and linked policies like BR and Error Msg to that Usecase. Then I copied that Usecase to another space.
My trouble is that the copied Usecase is linked to the policies of a different space. How can I use policies in the same space and link to those?
When you say "Usecase" I assume you are talking about a Process Blueprint.
If you copy a Process Blueprint, only the process is copied. None of the linked assets like Policies are going to be copied with it, so the copy will point to the same Policy as the original.
If instead you want to create copies of everything, you can copy the space instead of just copying the process. Assuming all the linked assets (i.e. Policies) are in the same space as your process, this will create copies of everything and the copy of your process will be correctly linked to the copy of the policies.
If all the assets are not in the same space, one workaround is to temporarily move the items you are wanting to copy into a temp space, copy that temp space and then move everything back to the original location.
I am relatively new to using Automator and I have been tasked with coming up with a way to duplicate files into multiple folders, as well as adding those images into subfolders.
I need to make a folder of images duplicate into two other separate folders, while deleting the originals after duplication. I have that part figured out and up and running without any problems.
But the next part has me stumped. I need to create a subfolder with the name 'Backup' with today's time on it, which I have done as well. Unfortunately, I need to move the duplicated files into it and I can't for the life of me figure out how to do it.
So the process is as follows:
Files dumped into 'Originals' folder
Files duplicated into 'Backup' and 'Retouch' folders
Deleting of files from 'Originals'
Creation of new subfolders in Backup and Retouch with a time stamp added to it
Moving of files from Backup and Retouch, into Backup and Retouch subfolders (with timestamps)
It has taken me this long to create all this, and I'd like to do it all automated without anyone having to select any files at all after starting the folder action. If there is any help that you might give me in this endeavor, I'd appreciate it.
Scenario:
A solution is checked into TFS. Changes are made to an offline/disconnected/unbound copy of the solution, which becomes "the latest" version. I want to update the repo with this disconnected copy's files.
How do I get TFS to look at all the files and determine which ones have changed, so it can check only those in?
If this were SVN, I would just plop the files on top of the existing working copy, and it would just work.
Do you have another copy of the solution that is bound to TFS? If not, you'll need one. You have two options:
Take the solution "offline" by right-clicking on the solution node and click "Go Offline". You can then copy your changed solution on top of the bound solution. When you load the solution again, right-click the solution again and choose Go Online. This will scan the disk and determine what has changed.
You other options is to run "tf edit" recursively on a bound solution, copy your changed solution on top of the bound one and then run "tfpt uu". "uu" stands for undo unchanged and it will undo changes to the files that are not different.
I cant think of any elegant way off hand but your best option would be to know what files were changed or added offline and connect them to the TFS version while removing the old TFS files.
To do this simply right click all of the old files and either delete them or exclude them from the project then move the new files into their physical folders and replace them with the updated version. If files were added then add them in the correct folders. Finally make sure all files are view-able in the solution explorer by clicking "show all files". Finally, right click the files you changed and select include in project for each.
This way you will have replaced only the files that were changed and won't have to check in the entire solution to TFS making it very unclear what files were changed with your check-in.
In case the question wasn't clear. I have 3 MVC projects in one Solution. Every time I create a new project it adds the "Scripts" folder with all the .js files I'll ever need. I don't want to have this created every time for every application. Is there a way to reference scripts from a central folder in the solution so all applications/projects can share one common script folder with all the scripts common among them?
Edit:
Please explain the pros and cons of doing this if there are any...now I'm curious.
Here is what I would recommend:
Right click the solution and create a New Solution Folder called Common Javascript Files (or whatever you feel like calling it.
Right click on the Solution, click Open Folder in Windows Explorer,
or navigate there manually for other versions of Visual Studio :(
In the solution directory, create a directory with the same name as the solution folder (solution folders do not normally match directories at the source code level but this will for sanity sake).
In this new directory, add files that need to be shared between solutions.
In Visual Studio, click the solution folder and select Add - Existing Item.
In the file selection dialog, navigate to the directory previous created, select the file(s) added to the directory and click Add.
In each Project that needs a shared file, right click on the project (or directory within the project) and click Add - Existing Item.
Navigate to the shared Directory, Select the files and click the drop down arrow then click Add As Link.
Now the files in the projects are essentially short cuts to the files in the Solution Folder. But they are treated as actual files in the project (this includes .CS or Visual Basic files, they will be compiled as files that actually exist in the project).
PROS
Files are truly shared across projects at Design time
Only the files needed for each project can be added, it's not all or nothing
Does not require any configuration in IIS (virtual directory etc)
If the solution is in TFS Source control, you can add the Directory to the TFS Source and the shared files will be source controlled.
Editing a file by selecting it in the Project, will edit the actual file.
Deleting a Linked file does not delete the file.
This is not limited to JS files, linked files can be ANY file you might need (Images, Css, Xml, CS, CSHTML, etc)
CONS
Each deployment gets it's own file.
There is a small learning curve when understanding that Solution Folders are not Directories that exist in a Solution Directory.
The best thing to do, imo, is to roll your own CDN... Basically just create another site in IIS and give it it's own binding, e.g. "http://cdn.somedomain.com"
Then store all of your css/js/fonts/shared images etc on the CDN site and link to them from your other sites.
Doing so solves 2 problems,
All of your stuff is shared when it needs to be and you only have to manage 1 revision per file.
Your users browsers can cache them in 1 single location instead of downloading copies of your stuff for every site that uses them..
I added this answer because I see a lot of people referrencing creating virtual directories. While that does indeed share the files, it creates multiple download paths for them which is an extreme waste of bandwidth. Why make your users download jquery.js (1 * number of sites) when you can allow them to download it once on (cdn.somedomain.com).
Also when I say waste of bandwidth, I'm not just talking about server bandwidth, I'm talking about mobile users on data plans... As an example, I hit our companies HR site (insuance etc) on my phone the other day and it consumed 25mb right out the gate, downloaded jquery and a bunch of stuff 5 times each... On a 2gb a month data plan, websites that do that really annoy me.
Here it goes, IMO the best and easiest solution, I spent a week trying to find best and easiest way which always had more cons than pros:
Resources(DLL)
Shared
images
image.png
css
shared.css
scripts
jquery.js
MvcApp1
Images
Content
Shared <- We want to get files from above dll here
...
MvcApp2
Images
Content
Shared <- We want to get files from above dll here
...
Add following to MvcApp1 -> Project -> MvcApp1 Properties -> Build events -> post build event:
start xcopy "$(SolutionDir)Resources\Shared\*" "$(SolutionDir)MvcApp1\Shared" /r /s /i /y
Here is explanation on what it does: Including Build action content files directory from referenced assembly at same level as bin directory
Do the same for MvcApp2. Now after every build fresh static files will be copied to your app and you can access files like "~/Shared/css/site.css"
If you want you can adjust the above command to copy scripts from .dll to scripts folder of every app, that way you could move some scripts to .dll without having to change any paths,here is example:
If you want to copy only scripts from Resources/Shared/scripts into MvcApp1/scripts after each build:
start xcopy "$(SolutionDir)Resources\Shared\Scripts\*" "$(SolutionDir)MvcApp1\Scripts" /r /s /i /y
This is a late answer but Microsoft has added a project type called Shared Project starting Visual Studio 2013 Update 2 that can do exactly what you wan't without having to link files.
The shared project reference shows up under the References node in the
Solution Explorer, but the code and assets in the shared project are
treated as if they were files linked into the main project.
"In previous versions of Visual Studio, you could share source code between projects by Add -> Existing Item and then choosing to Link. But this was kind of clunky and each separate source file had to be selected individually. With the move to supporting multiple disparate platforms (iOS, Android, etc), they decided to make it easier to share source between projects by adding the concept of Shared Projects."
https://blogs.msdn.microsoft.com/somasegar/2014/04/02/visual-studio-2013-update-2-rc-windows-phone-8-1-tools-shared-projects-and-universal-windows-apps/
Info from this thread:
What is the difference between a Shared Project and a Class Library in Visual Studio 2015?
https://stackoverflow.com/a/30638495/3850405
A suggestion that will allow you to debug your scripts without re-compiling the project:
Pick one "master" project (which you will use for debugging) and add the physical files to it
Use "Add As Link" feature as described in Eric's answer to add the script files to the other projects in solution
Use CopyLinkedContentFiles task on Build, as suggested in Mac's comment to copy the files over to the second over to your additional projects
This way you can modify the scripts in the "master" project without restarting the debugger, which to me makes the world of difference.
In IIS create a virtual folder pointing to the same scripts folder for each of the 3 applications. Then you'll only need to keep them in a single application. There are other alternatives, but it really depends on how your applications are structured.
Edit
A scarier idea is to use Areas. In a common area have a scripts directory with the scripts set to be compiled. Then serve them up yourself by getting them out of the dll. This might be a good idea if you foresee the common Area having more functionality later.
Most of the files that are included by default are also available via various CDN's.
If you're not adding your own custom scripts, you may not even need a scripts directory.
Microsoft's CDN for scripts: http://www.asp.net/ajaxlibrary/cdn.ashx