I am having a problem installing Indy10 into C++ Builder6.
Everything goes to great when installing the package and the components
display in the Indy tabs
but after closing and restarting BCB get the following messages
"This application has failed to start because IndySystem60.bpl was not
found. Re-installing the application may fix this problem"
After clicking OK I get
"Can't load package C:\Indy\Indy10\C6\dclIndyCore60.bpl.
The specified module could not be found."
I get the same messages for the IndyProtocols60.bpl
Once BCB starts all the Indy Tabs are gone and in Component Install Packages
the Design packages
Indy 10 Core Design Time and
Indy 10 Protocols Design Time are unchecked.
The Path is added to the Tools || Environment Options || Library Path
One thing I do note is in the C6 directory there is 2 design time files
dclIndyCore60.bpl and dclIndyProtocols60.bpl
but there are 3 runtime files
IndyCore60.bpl, IndyProtocols60.bpl and IndySystem60.bpl
Removing and adding them again brings them back but restarting BCB it all
starts again.
What am I doing wrong that is causing these to not be found when BCB starts.
Thanks
The BPL files are not located in a folder that is on the IDE's BPL search path, that is why it cannot find them when the IDE is restarted. Either move the files or change the search path. The Library Path is not the correct search path for BPL files, it is for OBJ and non-Package LIB files instead. Use the BPL output dir search path instead for BPL files. Also, if you compiled BPI/LIB files for the Packages, use the BPI/LIB output dir search path for them.
And yes, there are 2 design-time packages but 3 run-time packages. The IndySystem package does not register any design-time pieces.
Related
I learned how to make an installation package through this tutorial, but I encountered a problem.
https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=vs-2019#install-the-visual-studio-setup-and-deployment-project-template
I made the installation package strictly according to the tutorial. After clicking Primary Output, all the DLL files I needed appeared in the list on the right, but after I Build Solution, the names of the DLL files in the list were all cleared, and I got the installation package There is no DLL file either.
I found that when I added Project Output, the DLLs all appeared in the DetectedDependencies directory. Is there any problem?At this time I choose to generate the project, these DLL libraries will disappear, and the installation package does not contain any of them
enter image description here
I solved this problem. I added the files manually and added the DLLs I needed one by one to complete the packaging. When I click the Primary Output button, the DLL list automatically generated by the system seems to be invalid. Just ignore it. This may be a BUG
I'm using Microsoft Visual Studio Professional 2017 to build a project that uses the Poco libraries.
Background:
Don't know if this is pertinent, but I'll just mention that I manually downloaded and built Poco (and all the other libs needed), and everything went fine for years. Now I switched to using Miniconda3 to manage my libraries, installing Poco via conda install -c conda-forge poco and changing the relevant include paths from
$(POCO_DIR)/Foundation/include
$(POCO_DIR)/Util/include
...
to just
$(CONDA_LIBS)/include
with the system variable $(CONDA_LIBS) = D:\CodeLibraries\conda_libs\Library. This CONDA_LIBS directory exists and contains an include/Poco/ subdirectory with all the Poco header files and subdirs.
Problem:
The project compiled fine. I got a linker error, and while digging into this I found some odd behavior of Visual Studio 2017:
When I'm moving the cursor to an #include directive using any Poco header file, e.g.
#include "Poco/DateTime.h"
I can usually type CTRL+SHIFT+G to open and jump to the file in question.
This doesn't work anymore, and I get a popup telling me
D:\CodeLibraries\conda_libs\Library\include\oco\atetime.h
Cannot open file.
Note the missing letters in \(P)oco\(D)atetime.h. Note, also, that a file is found, but cannot be opened.
When I try this with a header file in a subdirectory like
#include "Poco/JSON/Parser.h"
I get the message
D:\CodeLibraries\conda_libs\Library\include\oco\son\rser.h
Cannot open file.
Note the missing letters "P", "J", and "Pa"(?!) in (P)oco\(J)SON\(Pa)rser.h.
Additional information:
The same error pops up when I drag-and-drop a Poco header file from the Windows Explorer into Visual Studio (!)
I can open these files from the Open File dialog (CTRL+O)
I can still use the CTRL+SHIFT+G shortcut to open my own header files in my project, and to open other library header files like gdal.h or boost headers
if I #include "oco/ateTime.h" (note the missing letters) and attempt to open it via CTRL+SHIFT+G I get the expected message "File 'oco/ateTime.h' not found in current source file's directory or in build system paths", with the paths listed below including D:\CodeLibraries\conda_libs\Library/include.
Question:
Any idea why both the CTRL+SHIFT+G shortcut and the drag-and-drop operation fail for Poco header files?
EDIT:
Please note:
I'm not asking about generic "File not found" errors: I can usually handle my include and lib paths quite well, thank you
slashes and backslashes can be used pretty much interchangedly in Visual Studio for the last couple of years at least
"Cannot open File" error could be due to a misconfiguration in your project include and source paths or due to a third-party extension or maybe even due to a corrupt/buggy IDE, but it has nothing to do with linker errors as you have also mentioned. You have also confirmed that the files are getting compiled, so this is surely some issue with the IDE's built-in code navigator or an extension.
With respect to linker errors, the project Configurations, lib target, library & header file versions you are referring to should match while linking against third-party libraries.
These are some general checklists for linking third-party libraries:
Runtime library: MT, MTd, MD, MDd, etc
Character set: Unicode or Multibyte
Target compiler
Target Machine
Subsystem
Whether the third-party library being used has additional dependencies, and you are properly linking the exact version of them.
These are checklists specific to POCO:
POCO version you are referring to in header files vs linker path
configurations.
OpenSSL version you are linking your project against, if you are
using SSL, Crypto and NET modules of POCO.
The same setup on my machine (but with VisualStudio 2019 configured for VisualStudio 2017 target) works just fine.
Odd.
When I returned to the office today, I wanted to look into this again to see if I could find out more about IntelliSense not finding POCO headers and about the odd dropping-characters thing in the error message, but it works now:
yes, I can once more jump to a POCO header file by moving my cursor to the #include line and hitting CTRL+SHIFT+G.
No idea if it was restarting VS that fixed this, or fixing the linker error -- which was trivial, BTW, and I might even have done at the side that while writing this question. Unfortunately I either didn't recheck for broken IntelliSense behaviour after the linker fix, or didn't bother recording that IntelliSense still was broken afterwards.
So: no real closure, I'm afraid.
EDIT: Ramesh Kambadaasan's answer suggests that a workaround might be to delete the IntelliSense DB file(s) and to restart VS to force a project re-parse. I'll try that next time.
In Windows you should use "\" as a directory seperator, not "/".
My guess is that VS replaces your "/" with "\", then the first letter of every word is an unescaped character.
Try to replace your "/" with "\\".
I've searched far and wide for a solution to this but can't find one.
I have configured TeamCity to publish packages with both the symbols and source in them to ProGet. This process works great and ProGet correctly identifies the symbols.
I have setup Visual Studio as per the instructions on ProGet's knowledge base i.e.
Adding the symbol locations in options->Debugging->Symbols
Enabled source server support options->Debugging->general
I've checked in Fiddler and the symbols are downloaded when I launch our app in debug.
Then when stepping in to one of the methods in our package it opens the wrong file. The file it opens is however named the same (we have a file called Component in each of our packages and also in local solution that pulls in the package).
If I change the name of the file and re-package and publish it to ProGet the problem goes away and I can step in to file during debugging but this seems like a hack.
Does anyone know how you can get Visual Studio to favour the file on the symbol server over any local files in the solution with the same name?
Symbol files in the project directory are always loaded, for this issue, a sample could help us understand the symbols loaded easily. If your local cache folder had the symbols file which was downloaded from the Symbol Server before, I know that it would not download it again during you debug your app. So my understanding is that since your symbol file has the same name, the VS debugging would search and load the symbol from your local project folder firstly, and then download it from the symbol server or others if your local machine has no them. That's the reason why you got this issue.
The workarounds I could think of:
(1) Load the symbols manually from Debug modules windows if you really want to use two files with the same name.
(2) Using different names would be better.
Right Click on the project containing the file you want to open and choose "Set as StartUp Project".
Now when you try to debug, it will run the correct file.
I have a winforms .net4.5.2 application which depends on a c++\cli wrapper which is included in the VS project by reference. When the winforms application, that is built using Any CPU, is launched a assembly resolver is used to point out the correct platform dll for the reference and Assembly.Load(ed) in the platform specific folders in the root of the application folder i.e. \x64 or \x86.
This c++\cli is now built using the v140 platform toolset which depends on the Universal CRT dll:s. Looking here https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ I was able to locate the necessary dll:s (41 * 2 of them) and I did what I was told to copy them inside the \x86 and \x64 folders. Now since the change to v140 platform my application does not start anymore and ProcessMonitor file operations tell me the following:
SUCCESS C:\MyApp\x64\TheCLIWrapper.x64.dll
SUCCESS C:\MyApp\x64\ADependency.dll
SUCCESS C:\MyApp\x64\msvcp140.dll
SUCCESS C:\MyApp\x64\vcruntime140.dll
SUCCESS C:\MyApp\x64\api-ms-win-crt-runtime-l1-1-0.dll
NAME NOT FOUND C:\MyApp\ucrtbase.dll
How is this even possible if before assembly resolving my c++\cli wrapper I explicitly set the dll directory (using SetDllDirectory) to the C:\MyApp\x64 folder? By this I mean why is the loading process looking in C:\MyApp for the ucrtbase.dll?
Naturally, if all the 41 dlls of a specific platform are copied to the root C:\MyApp\ folder it works but this is not an option for me, nor is the installation of c++ runtime executable on the clients running the application.
Does anyone have an idea or any tips on how to solve this deployment problem?
So you basically wanna do x-xopy deployment with x86-dll's in MyApp\x86, and x64-dll's in MyApp\x64?
How about explicitly loading the dll's with LoadLibrary?
I used procmon to inspect where the UCRT DLLs were trying to load each other from. Noticed the paths it was searching did not include the path set from the earlier SetDllDirectory. No matter what I tried the paths it searched seemed to only include the default values.
The working directory was always included as per Dynamic-Link Library Search Order and the only solution I could get was to change the current working directory to the appropriate one, load the DLL with the UCRT requirement, and change it back. Nothing else worked (including changing PATH environment variable)
Note this is very much not threadsafe
I've got a TFS project with a NuGet package installed, and it references an assembly from that package. However, another copy of the same file is in a folder in the tree, and it is somehow overriding the reference and being used instead.
Even if I remove the reference entirely and manually point it to the correct path, the other file still is recognized and overrides the path.
Actual Case:
Correct Reference Path:
c:\Stratigen\Stratigen\packages\MonoGame.Binaries.3.2.0\build\net40\MonoGame.Framework.dll
Overriding Reference Path:
c:\Stratigen\Stratigen\Stratigen\Tools\MonoGame.Framework.dll
The file in "Tools" needs to be there because it is a build against SharpDX (API wrapper for DirectX) and is used to compile shaders for multiple versions of MonoGame, while the game should be running against the OpenGL version (unless I were to purposefully change something).
The especially odd thing about this is that I've had this file in the "Tools" folder this entire time, and for weeks never encountered this issue, yet now it's got this odd behavior.
It seems that having included the "Tools" directory in the project was to blame. This folder is already handled by TFS but since there are a few source files in there (for the shaders) I'd included the folder. However, this for some reason gave priority to the DLLs there over those from the packages. I'm going to re-add the source files but not the DLLs/EXEs from that folder and it should work fine then.