I am currently developing software that creates business logic as a library in Visual Studio and calls it from Unreal. During debugging, I follow these steps:
1. Edit my library source code in Visual Studio and build it.
2. Place the built artifacts in the Source folder of the Unreal project.
3. Edit the source code in the Unreal solution and debugging.
This process requires building in multiple environments, which is quite cumbersome. While there are no issues during Release Builds using CI/CD tools, the efficiency during development is lacking.
I would like to manage related projects together, similar to a Visual Studio solution (.sln), and build based on dependencies. It would be great to press a single debug start button in one environment to build and debug simultaneously.
One potential solution I considered is adding the library project to the generated .sln file. However, I realize that since the .sln file is generated repeatedly, it may not be possible to maintain those changes.
The core issue is that effectively, the way a c++ raw library manages the build process is different on how unreal engine projects are buillt. I’ve asked Epic if it would be possible to integrate it directly to the Unreal Engine solution, as a new project as you would do it normally with a visual studio solution and they have told me that is not as simple as adding it. This would mean to integrate it inside the “Generate Project Files”/built operation, and linking it correctly to the game project. It looks that the solution looks like more of an automated operation that copies and prepares the project, instead of adding the existing project as you would normally do in visual studio.
Also unreal has its own documentation on integrating Third Party libraries inside the project but I think it does not fit exactly on what you are looking for. I’ll add the link the documentation if it can help in any way:
Overall Epic recommends to add all the logic of your library within a third party plugin. This would require a prebuilt + headers of course. Epic has a relevant example that could help to set everything up if you end up using the plugin system for your library:
`// Copyright Epic Games, Inc. All Rights Reserved.
include “ExampleTPP.h” include “Misc/MessageDialog.h” include “Modules/ModuleManager.h” include “Interfaces/IPluginManager.h” include “Misc/Paths.h” include “HAL/PlatformProcess.h” include “ExampleTPPLibrary/ExampleLibrary.h”
#define LOCTEXT_NAMESPACE “FExampleTPPModule”
void FExampleTPPModule::StartupModule()
{
/**/
// This code will execute after your module is loaded into memory; the exact timing is specified in the .uplugin file per-module
// Get the base directory of this plugin
FString BaseDir = IPluginManager::Get().FindPlugin(“ExampleTPP”)->GetBaseDir();
// Add on the relative location of the third party dll and load it
FString LibraryPath; #if PLATFORM_WINDOWS
LibraryPath = FPaths::Combine(*BaseDir, TEXT(“Binaries/ThirdParty/ExampleTPPLibrary/Win64/ExampleLibrary.dll”)); #elif PLATFORM_MAC
LibraryPath = FPaths::Combine(*BaseDir, TEXT(“Source/ThirdParty/ExampleTPPLibrary/Mac/Release/libExampleLibrary.dylib”)); #elif PLATFORM_LINUX
LibraryPath = FPaths::Combine(*BaseDir, TEXT(“Binaries/ThirdParty/ExampleTPPLibrary/Linux/x86_64-unknown-linux-gnu/libExampleLibrary.so”)); #endif // PLATFORM_WINDOWS
if (ExampleLibraryHandle)
{
// Call the test function in the third party library that opens a message box
//ExampleLibraryFunction();
}
else
{
//FMessageDialog::Open(EAppMsgType::Ok, LOCTEXT(“ThirdPartyLibraryError”, “Failed to load example third party library”));
}
}
void FExampleTPPModule::ShutdownModule()
{
// This function may be called during shutdown to clean up your module. For modules that support dynamic reloading,
// we call this function before unloading the module.
// Free the dll handle
FPlatformProcess::FreeDllHandle(ExampleLibraryHandle);
ExampleLibraryHandle = nullptr;
}
#undef LOCTEXT_NAMESPACE
IMPLEMENT_MODULE(FExampleTPPModule, ExampleTPP)`This module code loads a precompiles dll. There are comments all around so it should be easy to understand.
This would also require that you still need to precompile your library. I would say to add some extra steps in the compilation of visual studio that copies to the Unreal plugin library as a quick work around but it looks implementing your library as part of the development is not intended by default by how unreal is expected. Would ask again and see if I can get any extra information.
I have been following that approach, but having to pre-build the library before building Unreal—and switch back and forth between those two build environments—feels a bit cumbersome.
If you happen to come across any additional information, I’d really appreciate you sharing them.
From speaking to an Epic dev, we came to the conclusion that probably the best way to manage this, is to build automatically the library from an external process like CMake or any external building tools, and attach it to the Unreal building process. Inside unreal from the .uproject file you can add some building “PreBuildSteps” and “PostBuildSteps” to execute any extra code you need. In this case you could execute a .bat for example that builds your library and copies all the resulting files to the unreal plugin directory.
The main idea would be that you execute the building of the external library from a .bat that ends up calling building and copying the resulting files. You can add PreBuildSteps to the .uproject and execute the .bat.
"PreBuildSteps": { "Win64": [ "echo PreBuildSteps...", "echo PreBuild Info: RootDir=$(RootDir)", "echo PreBuild Info: EngineDir=$(EngineDir)", "echo PreBuild Info: ProjectDir=$(ProjectDir)" ".../pathToBat/BuildAndCopyLibrary.bat" ] }, "PostBuildSteps": { "Win64": [ "echo PostBuildSteps...", "echo PostBuild Info: RootDir=$(RootDir)", "echo PostBuild Info: EngineDir=$(EngineDir)", "echo PostBuild Info: ProjectDir=$(ProjectDir)" ] }This is the recomendation I’ve gotten from Epic, hope it can help with your issue.