Using Code Gear Delphi 2007 (don't know if it matter), each time a ".bpl" package is compiled, a ".~bpl" file is created too.
What are ".~bpl" files? Are those files required or is there a way to avoid their creation?
It's the backup of the previous copy of the BPL file, just like the .~pas files are backups of the .pas files and the .~dsk file is a previous copy of your desktop settings file and the .~dfm is a previous copy of your .dfm file.
There's no way to avoid their creation, but they're harmless. I'm not sure why they would concern you, but you can always create a post-build event in your project to delete them after a successful build.
Related
I've written a small VCL program using Delphi CE. I want to publish the source code incl. forms on Github but I'm not sure which parts are essential to include in the repository so that others can load it in their IDE and compile it.
I recommend you to use default .gitignore file for Delphi of Github. By this way you can be sure that all required files will be posted and all unnecessary files to compile will be excluded.
The file is here:
https://github.com/github/gitignore/blob/master/Delphi.gitignore
If you have an existing repository and want to add a gitignore file, have a look at here: Apply .gitignore on an existing repository
You can also exclude this files:
.~
*.dsm
*.ddp
*.map
*.rsm
*.dcu
*.tds
*.local
*.identcache
*.dsk
*.stat
*.tvsconfig
Exclude too the content of directories:
__history
__recovery
In addition to the other answers, some commonsense advice:
Put whatever minimum set of files you think you need into git
Download yourself (into a separate folder)
See if the project builds
If it fails, add the missing file(s) and repeat
I've been publishing my site regularly without too much trouble. But today I noticed that it won't overwrite existing .cshtml razor files with the new versions. I publish, look at the folder, and see the files are still out of date. If I delete the file and then publish, it will put the new version there. But if the file already exists it won't overwrite it and my production website is out of date. I tried doing the option 'delete files before publishing' but it gives me an access error that it can't delete folders. I tried deleting the entire folder but then I lose my .svn folders and it won't recognize version control.
Is there a way to force the Publish command to overwrite my .cshtml files with the latest version? (note: the dll files get overwritten fine)
Have you set the Copy to Output Directory to Copy Always?
I use Build Action = Content too.
Seems like Read-Only attribute is set on files, so they can't be overwritten. Check VS Output window for signs of errors.
Advice: Try to NOT include generated files (this also means folder with published files) in source control. VCS tools usually tend to lock-up files they work on.
Having .svn files on Test/Prod server is also not a good idea.
I have a big project written in Delphi and I want to manage its sources using Git. I created Git repository, which includes my application's sources and 3rd party components. All that stuff is automatically building using msbuild.
The biggest problem is RES files. Some of them are updated every time I rebuild my application, some are not. Some have *.rc sources, some don't. I can't ignore all res files (.gitignore) because without resources my project will fail to build. Also, I can't include res files - they change from build to build, I don't want to see them in diffs.
What do you do with your *.res files under Git? Any advices?
Welcome to the club. The application .res file in Delphi is a pain in the lower back for everybody using source control. You want to use auto-inc-buildnumber but it messes up your scource control.
What I have done is
split the icon and the version resources like this:
{$R *_icon.res}
{$R *._version.res}
disable auto inc of the buildnumber
add a pre-build event to the project that
increments the build number in a .ini file corresponding the project
generates a .rc file with the version info from the .ini file
compiles a .res file from the .rc file
add the *_icon.res file to source control, it never changes so this is safe
add the .ini file with the version info to source control, it is a text file so it is easy to diff
The tool I have written for generating the version .res file is free software, available here and also from OSDN
I keep my project RES files in git (those that match the name of the dpr).
I believe the only reason the project RES file would change every time you build is if you have increment build number set, which to me either means you need to keep the res in source control or you don't care about the build number so you should turn off that option.
I do also have RES files that I build from RC, which change every compile, so I have a gitignore for *.res and I then add git add -f project.res for the project RES files
By definition, RES files are compiled RC files. So ideally you should ignore all RES files and commit only RC changes. If it happened somehow that you don't have an RC source for some particular RES file, then add only this "orphan" RES file to git - such files shouldn't change from build to build (cause there is no RC file to generate them from). If for some strange reasons (Delphi, huh) such RES files do change, then you are doomed.
Bottom line: RES files are compilation targets - no different from other binaries (obj,exe,etc)
It's strongly advised to disable the "Auto increment build number" in the project settings, with any kind of version control system. This way it's 'safe' to add the .res files to the repository.
I have been searching for a long time for a way to auto-update the build number in the version info in the project's .res file, but the best thing is to update an extra .rc with the version info. In practice though, I generally update the build number to the current subversion revision number only right before the final build for a release of the binaries.
I don't know GIT, but under SVN I simply only "SVN ADD" the few that matter, and not the automatically generated ones. Since unversioned files are excluded from diffs, that's taken care off too then.
Could you:
ignore all .res files
generate the .res files that can be generate (compiling the resources script .rc files)
add only the .res files without .rc files to generate them: if you had specified in a .gitignore that they are to be ignored, then adding them is ok: they won't show up in the diff.
We have multiple config files (app.DEV.config, app.TEST.config, etc) and a pre-build event that copies the correct config file to app.config. Obviously the configuration specific files are in source control --- but at the moment so is App.Config, and that shouldn't be.
How can I mark that one file as excluded from source control, but obviously not from the project.
I'm using VS 2005, and 2005 Team Explorer.
It's easy in TFS2012, create a .tfignore file
http://msdn.microsoft.com/en-us/library/tfs/ms245454%28v=vs.110%29.aspx#tfignore
######################################
# Ignore .cpp files in the ProjA sub-folder and all its subfolders
ProjA\*.cpp
#
# Ignore .txt files in this folder
\*.txt
#
# Ignore .xml files in this folder and all its sub-folders
*.xml
#
# Ignore all files in the Temp sub-folder
\Temp
#
# Do not ignore .dll files in this folder nor in any of its sub-folders
!*.dll
# EDIT https://msdn.microsoft.com/en-us/library/ms245454(v=vs.110).aspx#tfignore
# A filespec is recursive unless prefixed by the \ character.
Select the App.config file in Solution Explorer, and choose File -> Source Control -> Exclude App.config from Source Control.
There is a checkin policy (Forbidden Patterns Policy) in the MS Power Tools which lets you screen filenames against a regular expression. See: Microsoft Team Foundation Server Power Tools
While checkin policies are not completely foolproof, they are the closest thing TFS has to enforcing user-defined rules like what you're looking for.
(And as the others have said, you can also cloak a file or folder, which means it stays in Source Control and is visible to everyone else on the team, but it's not copied to your PC until you decide to uncloak it; or you can delete the file, which means it gets deleted from everybody's PCs when they get latest - but neither of these options will prevent such files being added to source control in the first place)
There is an option that is hard to find:
1. Select the file or multiple files in Solution Explorer
2. Go to File -> Source Control -> Advanced
and here it is
Keep in mind:
If you right click a file in Solution Explorer you only find "the most important options" not all :)
If all you want is to have a file in the project but not under source control with TFS, just go into SourceControl, delete the said file, and undo your checkout of the project file (it will attempt to remove the file from the project as well). Then check-in your delete of the file you are excluding. In the solution explorer you should see that there is no source control icon next to the file you're excluding. The project file should list a file there, but that file should now no longer be under source control.
Keep in mind, any other person will now see a missing file in the project when they get latest.
TFS allows you to cloak at the folder/file level. When something is cloaked, TFS won't attempt to sync it (much like a svn:ignore).
When setting up your workspace, cloak anything you want TFS to ignore. A more detailed how-to is here.
This worked for me:
One way is to add a new or existing item to a project (e.g. right click on project, Add Existing Item or drag and drop from Windows explorer into the solution explorer), let TFS process the file(s) or folder, then undo pending changes on the item(s). TFS will unmark them as having a pending add change, and the files will sit quietly in the project and stay out of TFS.
Source:
=">How can I exclude a specific files from TFS source control
Visual Studio 2013 (and 2012)
This feature is available by selecting the file(s) and going to:
File > Source Control > Advanced > Exclude ... from Source Control
This question was asked a while ago but it pertains to the same type of issue I was having.
The Problem:
We want to check in our code.
We then want build our project.
During our build we depend on Build Events to move files around so we have the proper files in place for the build process to complete.
When our Build Event tries to copy the files, we get Access Denied errors.
The Reason:
Team Foundation Server Visual Studio Plugin changes the Read Only attribute on our files to READONLY TRUE when we check in our files.
Build Event Example:
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
Above, we simply need to move a file from our Target Build Path (the bin\debug or bin\release folders) to our Project Folder. In my situation, this was so I could include project built files in my installer. My Installer wasn't grabbing them as part of the Project Output.
The Fix: (nearly kicked my self in the face when I figured this out)
New Build Event:
attrib -R "$(ProjectDir)SomeFile.ext"
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
attrib +R "$(ProjectDir)SomeFile.ext"
We're all having fun with Build Events right? Above I simply do 2 things, I remove the read only attribute, now the files not read only. Copy my file as I was originally wanting to. Then replace the Read Only Attribute (optional I guess) to keep Visual Studio and Team Foundations happy.
And yes... I'm still kicking myself in the face on this one.
I have a similar issue, my App.config contained sensible data (e.g. username) that this data should not by sync with TFS.
The article Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service describes an good approach to prevent this issue:
Use the "file" attribute of the "appSettings" element to reference an config file that is not added to source-control
If you have an older version than TFS2012 and thus can't create a .tfignore file or use the File > Source Control > Advanced > Exclude … option, you can try this:
Make a copy of the target file in Windows Explorer.
Undo Pending Changes (if any) on the target file in Team Explorer/Visual Studio.
Delete the target file in Windows Explorer.
Move the copy of the target file to the location of the deleted target file, and rename it so it has the same name as the deleted target file.
TFS now seems to ignore the changes in the target file. If you need to edit the file again, don't use Visual Studio, as TFS will then put the file back in the list of files with Pending Changes.
You can just simply select the file from your Source Control Explorer and Right Click on it, and the select the "Rename" option from there, and you can add ".exclude" at the end of the file name.
And then do remember to check-in the file, and after that you can see that your file is excluded from Source Control.
I have a multi-project solution being stored in TFS.
Each project has separate Debug/Release build configuration folder specified.
The main project's bin folder is "included" in source control because it contains some third party DLLs that are included in the repository.
Each reference is a "project" reference type as per MS/TFS best practices.
Every time I build the solution, VS/TFS copies all of the built dependencies for the main project into both the build configuration folder (debug/release), and the root bin folder. When the file appear in the root bin folder, they get added to source control (or if they were already there due to this same issue, checked out)
For now, I have removed the bin folder from source control, but this is less than ideal, because now each developer must maintain the local DLLs, rather than just getting them from source control.
My ideal solution would be to just use SVN instead of TFS, but I'm locked into this one.
What's the best practice in this scenario?
If you want to include binaries in your source control (and some people would burn you at the stake for doing so) I would do the following:
Create a "Binaries" folder inside the project
Copy the dependencies in there
Add references to those DLLS in that location
The project file will then contain relative paths to them, so you can safely include that directory in source control and have it work for all devs, without having to add your "bin" directory to source control.
After using the solution outlined in the above answer and comment, I've found that for some reason, one of the DLLs is not being copied to the bin folder when the solution is built. (Copy local is set to true for the reference.) The DLL is copied into the build configuration folder, but not the main bin folder. It is used in the application, so dependency checking should pick it up. As it is now, a runtime error occurs whenever code attempts to access this component (as would be expected with a missing DLL.
Any ideas?