To debug remotely with Delphi, now that the PAServer is normally used, one usually follows the following preliminary steps, as outlined on the online docwiki:
Create a remote profile inside your ide, in my case I'm calling it win7vm, this contains the IP address of the remote system, and a few options, and the PAServer connection password, but as far as I can see, it doesn't contain any context information like "I want to use the following remote folders".
The remote folders that are usually used to contain my target executable are usually a subdirectory underneath the scratch directory. If I configure the main scratch directory to be c:\scratch, and my remote profile was named win7vm and my project is name project1, then the IDE and PA Server are going to compile and deliver my executable to c:\scratch\win7vm\project1 and run it from there.
What I actually want is to have my executable be delivered to and run right in #c:\scratch#. I have a gigabyte of supporting files that all need to be in the same directory as my main executable and I don't want to have 8 copies of these supporting files. So, can this be done? Can I make PA Server NOT create a sub-folder with the name of my project and another for the name of my session? If so, is this done inside the paserver.config file, or on my client side, or somewhere else?
Update: I tried to change the Remote Path in the Project -> Deployment, but it does not work to use a relative path here. For example, change it to ..\..\ and the working directory in Project Options to ..\..\, but it still only delivers my executable to the folder c:\scratch\win7vm\project1 instead of directly into c:\scratch\
Update 2: It appears you can't do what I want, which is have the scratch directory be the main folder, and NOT create any sub-folders per-profile and per-project, and that if you don't like working in a scratch sub-folder, you should just set Absolute Remote Paths in Deployment and Absolute working folder in your project's Run options, and you should turn off restricted mode, however this means that the entire VM or machine you are remotely debugging can be manipulated by the PAServer, which is also hardly ideal. I believe that having a fixed root scratch folder would be a safer and more flexible way of working, so I'm leaving this question open, hoping to find an effective way to achieve a safe but flexible remote debugging technique.
Related
We are using TFS 2010 Build to deliver libraries on a fixed location. ( \\server\product-R0\latest )
Other team projects reference the library from this location.
On my build process I check if Build and unit tests passed, if it's ok I:
Transform web/app.config
Delete the latest folder using a "DeleteDirectory" activity
Create the latest folder using a "CreateDirectory" activity
Copy the binaries in the folder using "CopyDirectory" activity
I delete the folder first because if we rename an assembly the old one won't be deleted.
The issue is random and happen 40% of the time:
TF270002 : An error occurred copying files from
'D:\Builds\1\FooTeam\BarService\Binaries' to
'\\nas\Builds\BarService-R0\Latest'.
Details : Access to the path
'\\nas\Builds\BarService-R0\Latest\SomeFile.dll'
is denied.
If you launch the build several times it work.
I've try the usual dumb idea of "putting sleeps between steps to see what happens" but it don't solve the problem, it just seems to reduce the probability of it happening.
It's like TFS try to copy while still deleting the directory, some times it hangs on the directory creation step.
Anyone? Thank you!
The most elegant solution is to create a link instead of copying, something like
mklink /J D:\Drops\MyBuild_LatestGood D:\Drops\MyBuild_2014-06-13
Plus: No copy involved, same ACLs.
Caveats: this command works only locally, when the Drop share is located on the Build server. There are options also in the case of a NAS, as long as you are allowed to execute remote commands (e.g. SSH).
Another option is to create a network share on the desired folder, even if the disk is remote, as long as it reside on a Windows server.
I am having an issue where when I select to publish my MVC project to the file system so I may upload it later via FTP to my Web Host, it fails complaining of missing files.
Believing that it may think these files are required to compile the project, I copy them to the locations that it expects and it resolves the error but produces yet another error about another missing file.
These files incidentally are not required to run my Web Application but were simply files used during the initial test phase of my project. More specifically, picture files.
The next step I took to resolve the issue was to Clean and rebuild the Solution and Project Entirely with all those files it was referencing in the errors removed. The Project builds successfully and runs as expected.
I then attempt to publish to the file system and again it complains of those files as if its getting that information from somewhere other than obvious places within my Project.
I have deleted the object directory content, cleaned and rebuilt; again it references these files that don't exist anywhere within my Solution.
So my question is, Where exactly does the Web Publishing Wizard get the information it uses to copy the required files to the Target Location? I've checked the .pubxml file but there's nothing in there that would provide the information.
For instance, if I'd initially built my site using reference to a .png file then later use a .jpg file. The Wizard seems to be getting the metadata for the initial build somewhere and insists on inclusion of the .png file when it is no longer needed.
I believe I have Upgraded to the latest build and patches for VS2012. I am Currently running version 11.0.50727.1 and using .NET 4.5
I cannot find any relevant information on this problem so it may be a quirk in my Environment so I'm searching for some feedback.
If no answer can be provided, if I could simply know what folders and files are required to deploy an MVC site; I'll perform the deploy manually and trash the Wizard concept. I just thought it would be the most appropriate way to deploy but if its going to be a pain; I don't need it.
This is the Error:
Error : Copying file <relative path>\image.png to obj\Release\Package\PackageTmp\<relative path>\image.png failed.
Could not find file '<relative path>\image.png'.
The new file that replaced the old file is actually image.jpg and its in there. I could alleviate this error by copying the old file back to its initial location, but why should I if its no longer required?
We are using TFS to build our solutions. We have some help files that we don't include in our projects as we don't want to grant our document writer access to the source. These files are placed in a folder on our network.
When the build kicks off we want the process to grab the files from the network location and place them into a help folder that is part of source.
I have found an activity in the xaml for the build process called CopyDirectory. I think this may work but I'm not sure what values to place into the Destination and Source properties. After each successful build the build is copied out to a network location. We want to copy the files from one network location into the new build directory.
I may be approaching this the wrong way, but any help would be much appreciated.
Thanks.
First, you might want to consider your documentation author placing his documents in TFS. You can give him access to a separate folder or project without granting access to your source code. The advantages of this are:
Everything is in source control. Files dropped in a network folder are easily misplaced or corrupted, and you have no history of changes to them. The ideal for any project is that everything related to the project is captured in source control so you can lift out a complete historical version whenever one is needed.
You can map the documentation to a different local folder on your build server such that simply executing the "get" of the source code automatically copies the documentation exactly where it's needed.
The disadvantage is that you may need an extra CAL for him to be able to do this.
Another (more laborious) approach is to let him save to the network location, and have a developer check the new files into TFS periodically. If the docs aren't updated often this may be an acceptable compromise.
However, if you wish to copy the docs from the net during your build, you can use one of the MSBuild Copy commands (as you are already aware), or you can use Exec. The copy commands are more complicated to use because they often populated with filename lists that are generated from outputs of other build targets, and are usually used with solution-relative pathnames. But if you're happy with DOS commands (xcopy/robocopy), then you may find it much easier just to use Exec to run an xcopy/robocopy command. You can then "develop" and test the xcopy command outside the MSBuild environment and then just paste it into the MSBuild script with confidence that it will work - much easier than trialling copy settings as part of your full build process.
Exec is documented here. The example shows pretty well how to do what you want, but in your case you can probably just replace the Command attribute with the entire xcopy/robocopy command (or even the name of a batch file) you want to use, so you won't need to set up the ItemGroup etc.
I like to backup up the source code set for a project when I release a version. I use GExperts project backups, which seems to gather up all the files in the project manager into the ZIP file. You can also add arbitrary files to this file set, but I'm always conscious of the fact that I haven't necessarily got all the files. Unless I specifically go though the uses clauses and add all the units I have sources for to the project, I'll never be sure of storing all the files necessary to recreate the installable/executable.
I've thought about rolling an app to traverse a project, following all the units used and looking down all the search paths and seeing if there is a source file available for that unit, and building a list of files to back up that way, but hey - maybe someone has already done the work?
You should (highly recommend) look into Version Control.
e.g. SVN (subversion), CVS
This will allow you to control revisions of all of your source. It will allow you to add or remove source files, roll back merge and all other nice things related to managing project sources.
This WILL save your a$%# one day.
You can interpret your question in two ways:
How can I make sure that I backup at least enough files so I can build the project
How can I make sure that I backup not too many files so I can still build the project
The first is to make sure you can build the system at all, the second to allow you to clean up unused files.
For both, a version control system including a separate build system is the way to go.
You then - for each new set of changes - can use these steps to assure that both conditions hold:
On your daily development system, check in the new revision of your source code into your version control system.
On your separate build system, get the latest version of your source control system.
Build the project on the build system; if this fails, go to Step 1, and add the missing files to your version control system from your development system
Start removing (one-by-one) files from the project that you suspect are not needed, then rebuild until it fails.
When the build fails, restore that particular file from the version control system, then continue step 3 with the next candidate
When the build succeed you have the minimum set of files.
Now make a difference overview of the files in your version control system, and the build machine.
Mark the files that are in your version control system but not on your build machine as deprecated or deleted.
Most version control systems have good ways of generating a difference between the files on your development or build system against the files in the version control system (usually fine grained for each historic point in time you added/removed/updated files in your version control system).
The reason you want a separate build system (or two separate development systems) is that you want them to be independent: you use one for developing, and the other for checking if the build is still OK.
This is the first step that in the future you might want to extend this into a continuous integration system (that runs unit tests, automatically creates product setups and much more).
--jeroen
I'm not sure if you're asking about version control or how to be sure you've got all the files.
One useful utility I run occasionally is a program that makes a DirList of all of the files in my dcu output folder. Changing the extensions from .dcu to .pas gives me a list of all of the source code files.
Of course it misses .inc files and other non-.pas files, but perhaps this line of thinking would be helpful to you in some way?
The value of this utility to me is that a second housekeeping utility program then makes a list of all .pas files in my source tree that do not have corresponding .dcu files. This (after a full compile of all programs) generally reveals some "junk" .pas files that are no longer in use.
For getting a list of all units compiled into an executable, you could let the compiler generate a MAP file. This file will contain entries for all the units used.
We had a Project in our solution called DatabaseCreation - which was responsible for creating the database and running the scripts (contained in directories within the project).
Everything was fine.
We then wanted to make the creation of this database to be available from an app and from a console, so re-factored so that we had ...
DatabaseCreation.Core
DatabaseCreation.App
DatabaseCreation.Console
Core has the directories containing scripts, and the App and Console run them.
When built with Visual Studio the directories containing the scripts are copied to the Output bin directory (either App or Console) but problem is: when the build server runs, the script directories don't get copied to the bin folder.
We've tried with TFS and Team City. I realise I could just copy them over, but its frustrating that it works when building in Visual Studio!
Can anyone put me on the right track please?
Check the Build Type for the files in the scripts directory. Find that by clicking one or many files (ctrl+click) then hitting properties (often f4). You likely want them to be content with Copy Always or Copy if newer.
The files were set to copy always, but the build just wouldn't pick them up.
The slightly awkward work around was to add the files as links from one project to another.
Add Existing -> navigate to other project - Looking for the little arrow on the right of the add button -> press that, Add as link option appears.