Delphi 2007 on Windows 10 - Download Borland.xxx.Targets files - delphi

as described in
Delphi 2007 x Windows 10 - Error on opening project
I am looking for the following files as deleted by Windows update
c:\windows\Microsoft.NET\Framework\v2.0.50727\Borland.Common.Targets
c:\windows\Microsoft.NET\Framework\v2.0.50727\Borland.Cpp.Targets
c:\windows\Microsoft.NET\Framework\v2.0.50727\Borland.Delphi.Targets
c:\windows\Microsoft.NET\Framework\v2.0.50727\Borland.Group.Targets
The Windows.old folder is long gone, and I can't find those files in the ProgramData folder.
Can anyone upload and share them?
Thank you,
Fabio

On my reference system, these files are also in this directory:
C:\ProgramData\{B59CE2E6-B15A-4F23-BD0E-72BF2ADDC3C7}\core\7EFD2DA3\6C948720
Others seem to have them there as well.
And they are at https://gist.github.com/anonymous/ab801cd925e5e634518fd5592eb2a46e

Related

Delphi Rio after patching not starting

I just did a complete system rebuild (format C drive and go from there)... Win 10 Pro 64 bit. I reinstalled Delphi Rio, the INITIAL release (6.7GB).... Delphi started up fine. I had previously downloaded Delphi Rio Patch 2, (7.3GB), so I unzipped it, and ran setup. It automatically chose the middle option (Modify), so I left it at that... and installed. It appeared to run fine. After completion, I noticed that it had removed the Delphi icon I created on my desktop, and that the links in my start menu for Delphi no longer work... I did not investigate a whole lot, as I had a patch 3 (7.9GB) to install as well. I unzipped, ran setup, and again Modify was the default option, so I ran with that... no errors. When completed, I tried to run Delphi. I have what I think is the appropriate directory structure (C:\Program Files (x86)\Embarcadero\Studio\20.0\bin) with 298 files in the bin directory, however bds.exe is NOT one of the files. Any idea what is going on?
The only possibility I can think of is that I have let my subscription expire.... and I am not entitled to the patches, yet the Embarcadero support system let me download them. Could this be the explanation?
Updating a certain Delphi version is usually done like this:
Download new ISO file or web installer
Uninstall the Delphi version you want to update and keep the registry settings (you are asked about this during the process)
Run setup from downloaded ISO or web installer
Your approach of installing the newer version on top of the older one is clearly the wrong way.
This is also explained in the install instructions (readme file) that comes with every ISO or web installer.

Indy 10 fails to install into Delphi 5

I have Delphi 10 Seattle, but I have an older program I wrote in 1995 with Delphi 1. I have since moved it to Delphi 5 — because of all the old 3rd-party components I have used over the years, it would be a total re-write (at least a year) to move it into Delphi 10 Seattle.
One of my secure websites the program uses is soon going to require TLS 1.2. I have Indy 9 installed, and that has worked fine with TLS 1.0, but I understand the only way for TLS 1.2 is to install Indy 10. So far, I have been unsuccessful.
I followed the instructions to the word using the batch file method after removing any instance of Indy 9 (mainly renaming files and directories in case of the worse scenario).
I changed my Environment path to the correct D2 folder Indy's batch file created.
I installed both of the dclIndyCore50 and dclIndyProtocols50 BPL's in the package installer.
They both go in and are checked (enabled). Components were visible.
Then I exit Delphi 5 and either get the following error or the 2 packages are unchecked:
I have tried to move the all the files from the created 'D2' folder to a folder right off of my C drive in case it was some sort of Windows 10 permission problem. I changed environment paths to match and add those packages. Still, Delphi states it can't find the file.
Installation seems simple enough. What could I be doing wrong? I left a post in the Tools section of Embarcadero's forum, but I can see it is not used much. Search the forum and found '0' results. I sure how your Delphi experts can help.
Delphi 5 likes to see BPL related files in his directory.
(Of course you have to adapt the path specified in this example.)
Search for the **Indy*.* files, copy all with the same compilation date/time to Delphi5's folder. Look at next picture for the path and files.
If you have the files !! (Don't copy now first) Remove the previous assignment to the Component.
Press Remove to
Indy 10 Core Desig Time -> dclIndyCore50.bpl
Indy 10 Protocols Design Time -> dclIndyProtocols50.bpl
Close and Restart Delphi
Now copy the files to the Delphi folder!
Install Component Package
press Add (look at Image above)
goto ...\Delphi5\Projects\Bpl\dclIndyCore50.bpl
next Add ...\Delphi5\Projects\Bpl\dclIndyProtocols50.bpl
Make sure that the path to Delphi is in Environment
F:\Programme\Borland\Delphi5\bin;F:\Programme\Borland\Delphi5\Projects\Bpl;
Close and restart Delphi.

Delphi 7 to Delphi XE2 .res file issue

When I open a Delphi 7 Project in Delphi XE2 and open the Project Option I get an error:
"Unable to set Icon: Cannot open file "........\AppName_Icon.ico".
The system cannot find the file specified".
I also notice that the Version info of the Project is missing.
The Delphi 7 project has .Res file that has the MAINICON along with the version information stored.
Why is Delphi XE2 not able to use this .Res file to retrive the MAINICON & Version information.
Also if I try to compile the application in XE2 I get an error -
[BRCC32 Error] MtxReq.vrc(2): file not found: MtxReq_Icon.ico
The MTXReq.vrc file (a new file) is created and the MtxReq.res file is deleted.
Why is this happening? I don't want to loose my project icon and version settings from .res file.
Is there a way to force XE2 to use the .res file and not delete it?
Any help will be greatly appreciated.
Sorry I can't post a comment yet (need more repotation points) ...
Warren - here the reponse to your question (Wouldn't just deleting your .dproj file and keeping the .dpr only, have been faster?)
I deleted the .dproj, .dproj.local
Opened the .dpr in XE2 and it recreated the .dproj file.
It brough back the icon from the .res but I lost project version info. Only File Version and Product Version info got migrated but lost all other versioning info. (This is because of the default manifest file).
I then tried what I explained in Step 1 of my solution.
I open the .dproj file in notepad deleted the tag entries under and reopened the .dproj file and all my version info now was recovered. The problem here is the $(BDS)\bin\default_app.manifest.
Also I noticed that Version info is stored in tag under the tag in the .dproj file and once you delete the default manifest entries, the IDE pickups the version key information correctly from the .
So basically by deleting the .dpr file I skipped the step of extracting and adding the .ico file to the project, but had to edit the newly created .proj file and delete the entries for default manifest to retrieve the version info. (another solution would have been to manully add the version info and saving the project. I did not try this)
Update 2015: Remy's idea of recreating .DPROJ files carefully by hand, is excellent advice and should be considered first, even though my answer is marked accepted.
Delphi versions prior to XE2 used resource files as an INPUT and an OUTPUT in the compilation process. For example, your delphi 7 project icon is embedded in that .res file, which you "want delphi xe2 to use", however, that's problematic in delphi 7, and now flat out impossible in XE2. Instead you now treat the .res file as a pure output artifact, the same as executable files. Don't bother checking .res files into version control any more, and don't try to pretend that the .res file is the place where you permanently store your icons. It's an output file produced automatically by the compiler, as it always should have been.
If you are a modern developer, the old way Delphi 7 worked might have annoyed you (it sure annoyed me) because you have the interesting and unsolveable question about what to do for version control: Do you check in the .RES file, or don't you? There were drawbacks to both approaches, and the fact that .RES files are now output artifacts only in XE2 is for the best. So learn to live with that.
Now that XE2 supports icons not only for a PC but also for a Mac, it must handle things differently, and they have cleaned this up. This is the origin of the problem you're seeing with the .ICO file. I have seen exactly the same error, and I have ignored it, and simply added the icon back to the project after it has otherwise been converted.
Converting a delphi 7 project (.dpr and .cfg) to Delphi XE2 is not as big a problem as the conversions between various levels of .dproj files -- each version starting with Delphi 2005,2007,2009,2010, and onwards has implemented changes in the dproj format. When problems occur with converting these projects, I do not do as Remy suggests, because it's a waste of time. What I do is DELETE the DPROJ and let it convert up from a .dpr file only.
But Remy's advice to start from scratch has many advantages, including that you may simplify your project layout.
Anyways, here's what you do:
Ignore error.
Add icon to project yourself.
Continue merrily along, and don't worry about the deletion of the .res file, that's intentional, and for good reasons. A new one will be created whenever needed. The filename of the .ico file on disk will be read by using the contents of the XE2 .dproj file and compiled into the .res file, as it should be.
As is always the case, you should NEVER let the IDE convert a project from an older version to the newer version. The conversion RARELY works correctly. You should ALWAYS create a new project in the newer IDE and then add your existing source files to it as needed.
Thanks everyone for your inputs and suggestions.
After I submitted my posting, I tried these steps to resolve the .ico issue and the missing Version issue/version info carry over issues :
Step 1. Edited the .dProj file and removed the reference to default_app.manifest related entries under tag (My project platform is 32 bit)
I deleted all tags under this except tag related to namespace System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;$(DCC_Namespace)
Without this my application was always showing the version info as 1.0.0.0 and ignoring everything else that I had specified.
(I am not sure if this is a right step but it solved my version info issue. There may be a simpler/another solution for this...)
Step 2. Extracted the ico from the old .res file, named it and added that .ico file to the Project from the Project Options.
the physical .ico file is the the projects folder and will be checked in source control (VSS in my case).
These two steps bought me to what I needed and then I can modify the Version number and compile the project.
From this point on there are no issues.
These were much simpler than the total conversion/migration I had to do for my applications from D7 to XE2 - Unicode conversion, migrating customized Raize 5 componets to Raize 6, Turbo Power, Virtual Tree View, Hypergrid etc. etc. etc... Luckily I found XE2 versions of all these components.

Trouble with IDE and VCLZIP components

What is loaded into Delphi 2010 from a dsk file that could prevent Delphi 2010 from crashing when a project is loaded?
Let me explain. It is somewhat complicated.
When I installed Delphi 2010 I put it on a large USB Western Digital hard drive (R:) with only Delphi 2010, Delphi project folders and Delphi component folders on it.
I copied all of my projects and components to the USB drive in R:\Components and R:\Projects folders. I then removed all the *.dcu files and history folders and *.dsk files so that Delphi 2010 would load the correct files that I open from Drive R.
Then I installed nearly all of my components into Delphi 2010 from folders on Drive R and tested them all with out a problem. So far over the last 7 days I have not had a problem with any of the components or projects I installed from R drive. I had thought everything was just fine until I tried loading my VclZip projects into Delphi 2010 from Drive R.
After opening a project with vclzip component... all is fine for about 15-20 seconds... then without even touching the mouse or the keyboard Delphi totally crashes and i am left at the Vista desktop with a dialog what says an exception ocurred in bds.exe in the runtime debugger.
Trouble Shooting
If I copy the *.dsk file in the project folder from Drive D ( Delphi 2009 project folder) to the project folder on Drive R, Delphi 2010 opens the project from Drive R and it does not crash, but the wrong files from my Delphi 2009 projects folder on Drive D are loaded into the Tabs (I suspect as specified from the *.dsk file). If I close the tabs in the Delphi 2010 IDE with the incorrect files and reopen the files in the ide, by double clicking them in the project group Delphi does not crash and i can compile and run the project from Drive R in Delphi 2010 with no problems.
I have been working with Delphi since Delphi 1 and I have never seen this happen before among 10's of thousands of delphi projects over the years, but I must say I naver have installed a version of delphi on a usb drive before. The other thing that is strange is why do just projects with VclZip do this? No other projects of well over a 100-200 projects and demos compiled so far in Delphi 2010 act this way.
Obvously something is wrong but I have no idea what except maybe an environment path or some incompatable code in a component. Is there an environment path that could cause Delphi to crash? An official VCLZip component is not available yet but I suspect it will be done in several days. If the component is not causing the problem does anyone have any ideas or suggestions?
Hopefully I have explained this well enough for everyone to understand.
Components are loaded into the IDE process, so any error in a component can cause problems in the IDE. I guess there is something in the version of the VCLZip components you use that makes the IDE unstable and breaks it down. So this is a showstopper, indeed, but for the VCLZip components.
Like already said, .dsk files can be discarded and should not be copied over. I generally also don't copy the .dproj files over to other directories. I rather open the .dpk or .dpr files and have a new one generated. That ensures that all directories are set correctly with the defaults, etc.
The *.dsk contains nothing important, and will in fact cause problems when you copy it between folders/computers, as it specifies where to load recent files from. I don't synch *.dsk at all, and your safe to delete it.
The DSK file stores recent file locations, form positions, window positions, watches, other debugging info (breakpoints, etc.) and other settings that don't hurt too much to lose.

Install the latest build of Indy 10 on Delphi 2009 [duplicate]

This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...

Resources