The downloaded package from Docx4j with all dependencies contains dozens of jar files. I think docx4j-2.8.1.jar depends on all of them.
What is the syntax I should use to convert docx4j-2.8.1.jar and all its dependencies to .Net assemblies?
Answered at your crosspost in the docx4j forum.
Related
The IT industry loves to create buzzwords, some new, some are new twists on old things. In .NET Core I read about Packages, References, NuGet Packages, DLL files and Namespaces. I understand the simple basics/steps, but is there a consistent relationship between some/all of the above words?
Does a single Reference ALWAYS point to a single Package?
Is one Package ALWAYS made of one DLL?
Is NuGet Package same as a Package?
What is the relationship between DLL file and Packages? 1 to 1, 1 to many? None?
Creating a Reference - is doing what? Is it pointing to ONE Package or Many?
When I use "Using ABC.123.DEF;", am I creating a new Reference? If not, would I already have created a Reference to that? What does Creating a Reference do, includes the DLLs (other files) in my project, or just tells the compiler to do so at compile time?
Finally, what form does MetaPackage take in Core 3? Is it a NuGet Package?
DLL File
A .dll (Dynamic Linked Library) file is a library that contains code and data that can be used by more than one program, each project that uses it adds a reference to it
Nuget Packages
Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), when you use Nuget pckage manager console to add packages. if i write a library that would be usefull to other developers, i can publish it to Nuget as a nuget package
Read more about nuget packages
Package Reference
A reference is essentially an entry in a project file that contains the information that Visual Studio needs to locate the component or the service.
for example, if you want to use EntityFramework in your project, you need to install it with the following command
Install-Package EntityFramework
This adds a package reference in the .csproj file
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.1" />
Note: versions may vary
I want to download Nuget packages programmatically from the .NET core/.NET Standard projects
We have some console apps that are tools NuGet packages and I want to download those and start them as a background process.
Best way to achieve it is by referring NugetDownloader Nuget package in Project and use it to download any package programmatically(in dotnet core as well)
Install-Package NugetDownloader
Source code and help guide on the same is available at :
https://github.com/paraspatidar/NugetDownloader
Here is a quick sample on how to achieve it :
string packageName="Newtonsoft.json";
string version="10.2.1.0"; \\optional
\\initilize NugetEngine from NugetDownloader namespaces
NugetEngine nugetEngine = new NugetEngine();
nugetEngine.GetPackage(packageName, version).Wait();
sample client is also available at https://github.com/paraspatidar/NugetDownloader/tree/master/NugetDownloaderTestConsole
Alternately In case if you want to build your Nugetdownloader engine from scratch , then you might also refer https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/Description/DotNet/PackageManager.cs as it has something similar implementation , but that too much of code understanding and extraction.
In my u-sql script I'm using the JsonExtractor that have a reference to "Newtonsoft.Json", in this script I also use a Custom Processor that uses "Newtonsoft.Json" too.
The problem is that the version used in the Processor is different from the version used by the JsonExtractor and it fails when load de dependencies of "Microsoft.Analytics.Samples.Formats.Json.JsonExtractor".
Is there a way to redirect assemblies?
Each U-SQL database can only contain one version of any given assembly. For example, if you need both version 7 and version 8 of the NewtonSoft Json.Net library, you need to register them in two different databases. Furthermore, each script can only refer to one version of a given assembly DLL. In this respect, U-SQL follows the C# assembly management and versioning semantics.
You can find more info here:
https://learn.microsoft.com/en-us/azure/data-lake-analytics/data-lake-analytics-u-sql-programmability-guide#requirements
In your custom processor just declare an alias for your version, and then you can use multiple dependencies by version. Is it possible to reference different version of the same assembly into a single project?
I am trying to use BinDeps to download a package dependency. After reading the documentation I am still a little confused over the difference between Sources and Binaries.
Can someone explain how they are different?
If I just want to download a .so file from a specified URL, and have it placed in usr/lib, which one should I use?
Thank you.
I believe Sources are for downloading the actual source code of a project which would then use a BuildProcess or SimpleBuild to compile. Binaries is for downloading pre-compiled shared libraries.
Today I had a problem with some routing in my ASP.NET MVC 3 application (with Visual Studio 2010).
So I thought I install the ASP.NET RouteDebugger and fix my route problem.
After I get the package through NuGet my project doesn't build anymore:
referenced assembly ' RouteDebug' does not have a strong name
I could download the source of the RouteDebugger and build (and strongly sign) it myself, but that's not the purpose of NuGet isnt' it ;)
Anyone else had this problem and maybe fixed it?
Well, the problem is not really related to NuGet. You cannot reference unsigned assembly from a signed assembly. And because the RouteDebug.dll as contained in the NuGet package is not strongly signed you won't be able to use it if your application is strongly signed. So you basically have two possibilities to choose from:
Download the source code of RouteDebug and compile it yourself by signing it with a strong key
Remove the strong key signature from your hosting application.
It is possible to sign an already compiled assembly without having to use the source code. This is explained here: http://www.geekzilla.co.uk/ViewCE64BEF3-51A6-4F1C-90C9-6A76B015C9FB.htm. In short, you need to use ildasm to get the IL for the assembly, then use ilasm to regenerate the dll, this time signed:
ildasm SomeAssembly.dll /out:SomeAssembly.il
ren SomeAssembly.dll SomeAssembly.dll.orig (for backup purposes)
ilasm SomeAssembly.il /dll /key= keyPair.snk
But yes, using unsigned NuGet packages in a project with signed assemblies is a pain in the ass...
This is a recognized shortcoming of nuget, as discussed here.
This is a common problem as many nuget packages are not strong named. It is possible to work around this by dynamically giving any included nuget packages a strong name at build time. Include nuget add package "Brutal.Dev.StrongNameSigner" to your project.
Then in your .csproj file, add a reference thus:
<Target Name="BeforeBuild">
<Exec ContinueOnError="false"
Command=""..\packages\Brutal.Dev.StrongNameSigner.1.8.0\tools\StrongNameSigner.Console.exe" -in "..\packages"" />
</Target>
Then at compile time, your unsigned nuget references will get a signature generated, and your assembly refernces will be updated to match the newly generated signature.
nuget: https://www.nuget.org/packages/Brutal.Dev.StrongNameSigner/
project: https://github.com/brutaldev/StrongNameSigner
Add StrongNamer to your nuget dependency list and it will automatically sign any unsigned references without having to add any additional build steps yourself.
https://www.nuget.org/packages/StrongNamer/