I have never use TFS version control...so I will try to explain problem I'm facing..
I have a small application for language localization...app make changes to .resx files of the project hosted on TFS...problem is that source control does't see that .resx files has been changed?
Any suggestions?
You need to change the file type options, try this article. It might be what you're after.
Related
vscode keeps adding a file named .dccache. How can I prevent this?
It messes up the github diffs and I keep on having to add .dccache to the .gitignore for several different projects.
I can't find anything about why .dccache is being created in the first place
It can also be created by the Snyk extension.
I have the same file, I believe this is being created from DeepCode: https://www.deepcode.ai/
This is a code analysis tool to try to find issues. Check if you installed the DeepCode extension in VSCode if you want to get rid of this file, otherwise ignoring it should be fine.
The DeepCode plugins or the CLI is using this file to create a cache for the source code bundles send to the analysis engine. Without this cache, the collection and upload would be very time-consuming.
As it only serves as a caching mechanism, you can exclude it from git uploads and ignore it otherwise.
Snyk extention has a Help&Feedback tab, on the FAQ there is a 'Add custom .dcignore file to your workspace'.
Sometimes git ignore doesn't work for me
I used this file: https://github.com/DeepCodeAI/dcignore/blob/master/full.dcignore.js
just create .dcignore and copy all contents to that. I manually add .dccache and .dcignore just in case.
I had the same issue and when I disabled Snyk extension on VS code editor is disappeared, if you don't have Snyk installed and still have .dccache appearing every now and them, just keep an eye on the other extensions, disable each one at a time and see which one is creating the .dccache file
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
What should I check in/not check in? Since many of the files are sometimes auto-generated I'm not entirely sure how to handle this using version control...does it have something to do with tags?
For instance in ANT, I know not to check-in my target/bin directories...but Grails adds another level of confusion to this...since some of code is generated and some of it is not.
(It may become clearer as I go...but it seems to be that there needs to be some way of being able to tell what was just generated and what was modified by a developer so that it needs to be placed in version control)
Here's the .hgignore directory I've got on my most recent grails project (with a couple of project specific things taken out):
syntax: glob
out
target
logs
*.iml
.idea
*.iws
*.war
workspace.xml
lib/build
lib/compile
lib/runtime
lib/test
~$*
stacktrace.log
*.tmproj
*.launch
reports/
*.orig
*.zip
.DS_Store
*/.DS_Store
web-app/WEB-INF/classes
cobertura.ser
The generated code in Grails should be placed under version control. It's not secondary executable code that is generated by the build process like class files, but instead is code that is part of your source. The generated code is intended to be just a starting point for your application and will most likely be modified at some point anyway.
Also check this:
http://www.grails.org/Checking+Projects+into+SVN
and this:
https://stackoverflow.com/questions/4201578
We're using TFS and we're having problems when we switch branches, it's throwing up problems with the TFS bindings every single time.
We still have
.vspcc files
.vsscc files
which is I'm guessing where it stores the bindings, does anyone have any advice on how to easily switch between branches in TFS without pain?
These files are used to store files that are excluded from source control - and yes, they are themselves under source control. I've never had to worry about these before, so I don't think that's where the problem is.
Bindings are normally stored in your actual proj and sln files.
If you have problems with binding, you actually have some problem with your workspace. Either make a new workspace in a new local folder, and get everything from the server there from scratch (i.e. setting up the workspace mapping through visual studio, opening your solution via the source explorer etc. Don't use any clever tricks here - otherwise strange things happen), or try going to File -> Source Control -> Change Source Control, unbinding all projects and rebinding them. VS will blindly write the binding info anew into your project and sln files if you do this.
Especially make sure that all server paths you're checking out can be mapped to a local path.
Switching between branches is just done by opening the appropriate solution file from the appropriate folder/branch. It's not normal that this gives you problems, obviously.
I have created a web part using VSeWSS 1.3. It creates a wsp file and my web part gets installed, everything works great.
I would like to also create a folder in the LAYOUTS directory of the 12 hive and place a couple files in there. How do I go about doing this? I know that I can manually place the files there, but I would prefer to have it all done in one fell swoop when I uses stsadm to install my solution.
Is there a best practices guide out there for using VSeWSS 1.3 to do this? They changed a bunch of stuff with this new version and I want to make sure I don't mess anything up.
You can create a new folder structure in your webpart project, like:
Templates/Layouts/CustomFolder and put your files in the CustomFolder directory and include them in your project.
When you go to the WSP View in Visual Studio, you can see in the manifest.xml that your files are being included in the deployment.
I have done this successfully on multiple projects now.
In case anyone is wondering, the VSeWSS 1.3 user guide is incredibly helpful. It is installed to the same directory as the tool itself, default in C:\Program Files\Microsoft SharePoint Developer Tools 9.0\VSeWSS13.CHM
You can see a working example with screenshots Here
A simple step-by-step tutorial for the above, along with deploy/retract scripts is here at Add New Files To 12-Hive Through A SharePoint Solution. Just follow the steps and in a few minutes you'll be able to add whatever you want to the 12-Hive!