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.
Related
I am trying to publish a Netcore 2.0 application with MSBUILD.
The published output is missing all the SDK dlls such as Microsoft.AspNetCore.Hosting.dll (there are a lot) so when I try to run the application from command line with dotnet appname.dll I get the error saying that it can't find the referenced dll...
I have published other applications before (not created by me) and the publish copies the dlls and also has a "refs" folder which mine does not have.
So I am pretty sure it's a project configuration issue but I have been searching for hours and there is no information on what I should change.
Turns out there was a nuget reference on my project called Microsoft.AspNetCore.All...
For some reason uninstalling this reference solved the issue and now the publish output contains all the SDK dlls
The ASP.NET Core dlls are part of the runtime store that is included in the runtime & hosting bundle installations so they don't need to be included in the publish output. (note that this is going to change in the 2.1 timeframe)
To disable the use of the ASP.NET Core runtime package store, you can set this in your project file:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
.Net Core projects do not put the reference DLLs from the nuget packages in the bin folder. Is there a way of any properties that helps in doing that?
It's needed for some third party tools to understand the reference DLLs.
.NET Core, unlike .NET Framework, can resolve assemblies from half a dozen locations. This includes the NuGet cache, servicing cache, runtime store, local app directory, and shared framework folder. During development, these are typically found in the NuGet cache (%USERPROFILE%.NuGet\packages) This makes it unnecessary to copy referenced assemblies to the build output folder (bin) until you publish your application. For more details on how that works, see https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/corehost.md
You can force the SDK to copy assemblies to your build folder by setting the proper below, but it increase disk use and build time.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Or you can use the deps.json and runtimeconfig.json file to locate required assemblies.
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).
I have a Web Site and Class Library built with ASP.NET 5. The Class Library depends on an set of external files (XML, EXEs, etc.). Those dependencies are added as part of the project and visible in the Solution Explorer of Visual Studio.
My Web Site has a dependency on the Class Library. When I build the Web Site, I would expect the dependencies of the Class Library to be copied to the Web Site, but they aren't.
The Build Action (Copy always, Copy if changed) appears to be gone with ASP.NET 5. How do I make sure that dependencies other then the DLL of the Class Library itself gets copied to the Web Site project?
First thing first, they won't be in src/yourProject/bin/Debug. Those have been moved to the artifacts folder.
Also, your project by default will not output DLLs. This is mainly due to performance reason but if you need your DLL to publish your application, check your project properties. In the Build section you should have an option called Produce outputs on build. Tick that and bingo.
You have your dlls. Most of the time (aka: while coding), you won't need them since they will always be recompiled in memory.
You need to manually add a pre/post build step in project.json
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.