I'm developing a Petrel plugin via Ocean, both versions 2022, but when running the PluginPackager as part of the post-build of the PIP project, validation fails:
2> ERROR Plugin includes library that is already distributed by Petrel or another plugin, but it is not identical.
2> Plugin includes tbb, which conflicts with the same library in .
The error doesn't tell me which library but there are only three other instances of tbb.dll in the Petrel installation and various plugins, none of which are the same version as the tbb.dll I'm using.
According to the AcceptanceChecklist.xml, it seems that there should not be a validation error:
The plug-in may use 3rd party libraries deployed by Petrel. The Components list documents this set of 3rd parties.
The plug-in must not deploy any library on this list, unless a different version is required
Does anyone know how to pass validation when deploying third-party libraries?
Related
I want to package some tools as a nuget and am using the Microsoft.Build.NoTargets project SDK format to achieve the same.
As mentioned in the docs, NoTargets is used when the project file does not compile any assembly. However, it needs a TargetFramework property to be set.
msbuild fails with NETSDK1013 if I don't specify some TargetFramework property.
Why does msbuild mandate that TargetFramework be specified for the NoTargets SDK csproj?
Currently this is required for it to load in VS: VS checks if the project contains TargetFramework or TargetFrameworks in the xml to load sdk-based projects in the "new" project system (the thing that powers the IDE integration of the project). Otherwise it would use the legacy system that would not understand the features the SDK uses and either not load or give you a bad experience.
The MSBuild errors could be fixed in the SDK by defaulting the property but that will still fail IDE integrations.
Also note that the SDK imports other SDKs that are meant for .NET projects (language-independent over F#/C#/VB) and so you should get features like NuGet restore or packing working without much friction when a TargetFramework is set (even if it could be defaulted to whatever the SDK is basdded on in the NoTargets itself as mentioned)
I've created a program and would like to release it, but am currently struggling with dll dependency issues. How can I create a msi installer package that will properly install .dlls? Every solution I've found online so far has created msi packages that only include the exe.
Short Answer: Generally, the most common runtimes are: Java, Visual Studio C/C++ Runtime, .NET Framework. Try installing these on a clean virtual and try launching your application. Debugging application launch check-list.
Modern Deployment: Many Microsoft runtimes that we used to deploy are now part of Windows. An exception is the Visual Studio C/C++ runtimes. I am not sure why they are not just included in Windows at this point. In general you should not pick single dll files to deploy, you need to locate a merge module, a setup.exe or an MSI to deploy the runtime. Commercial tools have features to help you download such bundles.
Setup: The basic, general steps to create a setup are described here: How to create a windows installer for multi language program with outside dependencies?
Specific Runtimes: One can generally determine runtime requirements by looking at the application files (experience - trained eye), looking at the application GUI (visual clues), checking dependencies using dependency scanner tools, talking to the developers of the application, checking file properties of files you find to depend upon (Company name is a good clue), etc... Then you verify and test this on a clean, virtual machine. You keep installing runtimes manually until your application works. In the section "The Complexity of Deployment" here you can find a listing of common runtimes and technologies.
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
After that I successfully added Libgit2sharp.dll by add reference in my .NET Windows application. Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error:
a reference to 'C:\User\nitesh\git2.dll' could not be added please make sure that the file is accessible and that it is a valid assembly or COM component
Can anyone please help me understand the problem?
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
First off, this is not a distribution channel that the libgit2/libgit2sharp team has anything to do with.
Install as a NuGet package:
Official releases are available as a NuGet package if you prefer to download pre-built sources. See this post which explains how to install the NuGet Package Manager in Visual Studio.
This is the easiest way to make LibGit2Sharp available to your project.
Build from the source code:
You can download the source code and build the C# code into LibGit2Sharp.dll from https://github.com/libgit2/libgit2sharp, which includes the pre-built version of git2.dll which works for the particular version of the C# code.
Easiest way to build the assembly is by launching the build.libgit2sharp.cmd. This will create a Build folder into which you'll find the LibGit2Sharp.dll and a NativeBinaries folder with the native binaries.
Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error
As for the error message, it sounds like you're trying to add the git2.dll to the project as though it were a CLR/.NET assembly. It is however built from C and isn't something VS is going to do anything useful with. You do not need to add it to your project.
It does need to be available for libgit2sharp to load. The following graph depicts the folder hierarchy that libgit2sharp expects
NativeBinaries+
|___amd64+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
|_____x86+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
Note: This folder structure will be dynamically created in your project output folder if you installed LibGit2Sharp as a NuGet package. However, if you built the project from the source code, you'll have to copy this folder structure as part of your project build process yourself.
I have a set of utility LabVIEW VIs that make calls to a custom DLL written in C++. I'd like to package the VIs into a LabVIEW toolkit and deploy it via an installer, but am unsure about the standard practices involved in doing this where a custom DLL is involved. I've looked at VIPM for packaging the VIs, but so far I haven't found a way to generate a package and include the appropriate DLL dependencies. What is the correct way to go about generating an installer for a LabVIEW Toolkit and installing the DLL dependency for said toolkit in the correct location (where ever that may be)?
The DLLs immediately known to the system - i.e., the ones entered in the CLFN node - are added automatically.
DLLs which are used indirectly and DLLs which are determined programmatically cannot be auto-included and must be added manually to the Source files section of the respective Build rule.
I have an application which use CUDA. I am using runtime API and CUDA toolkit 3.2. Application has a dependency on cudart32_32_7.dll. However, there is also cudart32_32_12.dll. The issue is, I do not know how to determine which dll is linked from cudart.lib during the application build. I need to identify dependency dynamically somehow, because I need to include all dependencies into the deployment package. I would like to avoid hard coding dependency path ...
Just put the .dll or .exe of your project into this software: Dependency walker. It will show on what other .dlls yours project depends on. There you'll find either cudart32_32_7.dll or cudart32_32_12.dll.
Alternatively, if you're making a binary project. Just compile it and run the binary (.exe) on a different machine that doesn't have CUDA installed. An error message will come asking for either cudart32_32_7.dll or cudart32_32_12.dll.