I want to build a Class Library in ASP.NET 5 using VS2015, but as far as I can tell it only produces DLL files. These would then be packages as a Nuget package.
But does this mean that these DLL's would also work fine on a Linux environment? Or do I need to do something else in order to build a Nuget package that will also work on Linux?
Make sure you select the Class Library (Package) option under the Web node in the New Project window.
That will create a project that outputs a dll in a NuGet package
Related
I'm getting crazy here.
I created a Net-Core 6.0 DLL and set the PUBLISH settings as:
Release
Net6.0
Self-Contained
win-x64
Enable ReadyToRun compilation
The library has 4 Nuget packages and a set of custom libraries present on my disk.
When I publish, I see only the DLL within the RELEASE folder and a ".nupkg" within the "win-x64" folder. Where are all the required DLLs of my project, including the Nuget Packages and dependencies?
When I created another console app some days before, I could see all of them in PUBLISH folder.
I appreciate any help on this.
EDIT
I created another project (a Windows Forms App) to link this DLL. Both contain the same NuGet packages and libraries. When I publish the solution, I see the expected results. But again, if I publish ONLY the DLL project, I see only the above explained.
I have a project ("Project1") that has a reference to an Assembly that I created in another project ("Project2").
I just added a function to a class in that assembly, but that function required me to add the NuGet package System.Drawing.Common. Which isn't an issue.
Here's the issue:
When I build Project1, it does not bring System.Drawing.Common.DLL to the bin folder. So, at runtime, when I execute this new function, I get an error stating that it can't find this DLL.
Is there a way that I can have Project1 bring along all of the Assembly's dependencies? Or do I have to instead add all the same NuGet packages that Project2/Assembly uses to Project1?
I'd prefer the former. I'm using ASP.NET Core 2.2 and Visual Studio 2017.
Thank you.
The build command with .NET Core 2.2 does not bring in the dependencies by default this is for testing only. If you are wanting all the dependency .dll to be included for deployment you should use the publish command to get all the .dll from your NuGet packages. There are other switches to include the framework as well so you don't need to install the framework, on the host.
As a friendly reminder, Dot Net Core 2.2 support will end on December 23, 2019
I have the same problem as described here:
https://github.com/NLua/NLua/issues/33
Though I have followed the instructions to create a console application...
http://www.screencast.com/t/M12TqePQxW
...which works just fine, when I create a library project and reference it from another project (in this case, a Web API project) the following error occurs:
Unable to load DLL 'lua52': The specified module could not be found.
At this line:
using (var lua = new Lua())
How can a library project be made with the NLua nuget package without failing?
It is the exact same issue as described in the GitHub issue, the Nuget package is missing two DLLs that you need to use lua52.dll. One small difference, the current package (version 1.3.2.1) includes a newer version of lua52.dll that was built with VS2013. And therefore has a dependency on msvcr120.dll and msvp120.dll.
Beware that this may change in the future when Nuget updates your project.
As-is, you need to download and install the Visual C++ redistributable package for VS2013. Run both vcredist_x64.exe and vcredist_x86.exe so your project can run either in 32-bit or 64-bit mode.
To avoid having to do this on the machine on which you want to deploy your program, I recommend you copy the two DLLs from the c:\windows\system32 (64-bit) or c:\windows\syswow64 (32-bit) directories into the same directory as your EXE.
The package author could have done a better job putting this package together. Short from including the DLLs in the package, the better solution would be for him to rebuild lua52.dll with the /MT option so these dependencies are linked in. Consider clicking the New Issue button to let him know.
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.
Create new Windows 8 application App1
Add ClassLibrary1 Windows 8 class library project to solution
Add PortableClassLibrary1 portable class library targeting Windows 8 and Windows Phone 7.5 to a solution
Reference HttpClient nuget package in ClassLibrary1
Reference HttpClient nuget package in PortableClassLibrary1
Reference both ClassLibrary1 and PortableClassLibrary1
Compile solution
You get an error at .appx package stage
Payload contains two or more files with the same destination path 'System.Net.Http.Primitives.dll'.
Source files:
\Projects\App1\PortableClassLibrary1\bin\Debug\System.Net.Http.Primitives.dll
\Projects\App1\packages\Microsoft.Net.Http.2.2.13\lib\win8\System.Net.Http.Primitives.dll
Please note the same error is reproduced if you reference any nuget package featuring both win8 and portable blends of assemblies.
What is expected:
Most specific version of a library (win8 one) is packaged into .appx and portable version is ignored
Any ideas on how to cheat appx packager and build this kind of Windows 8 projects?
It looks like the solution described here works: http://cyanbyfuchsia.wordpress.com/2013/05/03/payload-contains-two-or-more-files-with-the-same-destination-path/
Basically, you must set "Copy local" to false in the WinRT project that is referenced from the main app.
In addition to this, you should be getting warnings similar to:
All projects referencing ClassLibrary1.csproj must install nuget
package Microsoft.Bcl.Build. For more information, see
http://go.microsoft.com/fwlink/?LinkID=317569.
This is indicating a problem. Basically, the short of it, you should be installing HttpClient.Compression into all projects. MSBuild/AppX packaging doesn't know which binary to deploy between the portable library and store library project (they have different APIs & versions). Installing the package into the application, tells it.
I had such issue too. It was because I shared one of my solution between projects. I had to rename the solution, because the name was all the same like one of the projects. After renaming I had this problem.
I fixed it by: right click on solution I renamed and used both projects, then properties, then use same name in the assembly name like solution name.