I have a project (.NET Core targeting .NET 4.6.1) that has lots of libraries in it. When I build the project from Visual Studio all assemblies are created correctly.
But when I delete the bin and obj folders and try to rebuild from PowerShell with dotnet publish, one of the libraries' assembly gets created badly; it's only half the file size and it doesn't work when I run the functionalities of that library.
The problem exist because I need to publish it through Team City so I can't do it from Visual Studio.
Anybody got any idea why it's behaving like this?
Related
I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
I recently upgraded my Unity C# project's .NET version from 3.5 to 4.5.2. Everything compiles beautifully in my Visual Studio project, but i have errors in my Unity Console which are not showing in VS and these errors are prohibiting me from running my project. It seems as though my project didn't actually upgrade to 4.5.2, is there any way to solve this?
EDIT: i've tried upgrading unity's framework version by going into Edit -> Project Settings -> Player -> Configuration -> Scripting Runtime Version and changing that value to .NET 4.x Equivalent but it changed nothing
Do you have a copy of the MySql.Data.dll in your Assets folder? References in Unity work differently than in Visual Studio. You add a reference in Unity by dropping the .dll into the Assets folder (preferably in a directory that makes sense, not at the root so that it is easy to find and doesn't clutter the root). You should always get your code working in Unity first and then compile in Visual Studio, not the other way around.
Is it possible to make Visual Studio to copy all dependencies of referenced projects into the output path?
Example
In the Solution, Project A (Library, .NET Standard) defines some functions and is dependent on Library L1 (via NuGet) and Library L2 (local .dll, referenced and copied to project)
Project B (Console Application) references Project A.
When building B, The output folder contains all direct dependencies of B and A.dll. L1 and L2 are not available in the output. Therefore, the program does not work correctly.
How can I force VS to copy also L1 and L2 to the output of B?
The only way I found so far is packing A as NuGet, but this seems to be unnecessary overhead and uncomfortable. I think I am just forgetting something everyone else seems to know...
Edit (clearifying Example)
My solutions consists of two projects.
Project MongoWrapper
.NET Standard 2.0 class Library
depends on NuGet MongoDB.Driver package
Actually uses this dependency (no zombie dependency)
Project ConsoleUser
.Net Framework 4.6.1 Console Application
References MongoWrapper project
Actually uses MongoWrapper
Observation
When debugging the ConsoleUser application, it compiles and starts. During runtime, when it calls a method in the MongoWrapper which uses the MongoDB.Driver, the application crashes, as the MongoDB.Driver dependency was not copied into the output folder of the ConsoleUser.
How to fix this?
The problem was introduced by the usage of .Net Standard library and a .Net Framework application.
TLDR
Open the .csproj file of the .Net Framework project with a text editor. Inside the first PropertyGroup add the line
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Save the file, reopen Solution in Visual Studio and perform Clean & Build
Dependencies in different project file versions
.Net Framework projects use an old version of the .csproj project files. References/Dependencies are stored in the additional packages.configfile. By default, building a .Net Framework project makes the system to search for a packages.config file in the referenced projects. If no such file is found, the build task treats the referenced project as having no dependencies. Therefore, in the example, the MongoDB.Driver library is not added.
By adding the proposed line in the .csproj project file, the build task searches the project file of the referenced project for dependencies, where they are stored in .Net Standard project files.
.Net Core projects by default search for the newer project file structure.
The default behavior for new projects can be set in the Options -> NuGet -> General -> Package Management
Is it possible to make Visual Studio to copy all dependencies of referenced projects into the output path?
Yes.
This is what publishing the application does - it prepares the application for deployment. When you publish, it will include all of the dependencies that the application requires to run in the output.
Use the Publish tool to deploy to a local folder. The exact options available depend on your app type. In Solution Explorer, right-click your project and choose Publish, and then choose Folder. For more information, see Deploy to a local folder.
Tutorial: Publish your Hello World application with Visual Studio 2017
Also see: .NET Core application deployment.
I am attempting to use Visual Studio Installer Projects to make an installer for my app. I am using Visual Studio 2015, and my app is built using WPF and .NET 4.5.
I was following this general tutorial on how to make a Visual Studio Installer Project: https://www.youtube.com/watch?v=z0v6hmumCFU
When I include the "primary output" of each of my projects in the installer, it goes out and identifies the dependencies of these projects and includes them as files that need to be in the installer. I am puzzled, however, because it even seems to be including several standard "system" .NET DLL files, as you can see in this image below:
I tried building it, and then running the installer that it builds, and sure enough it installs all of these "system" DLL files into the install directory.
My understanding is that these DLL files should be on the user's computer already in a standard location once the user has installed .NET 4.5 or later, so my installer shouldn't need to copy over many of these dependencies into the install directory.
So my question is thus:
(1) Why does the Visual Studio Installer Project extension include these dependencies which are obviously part of .NET and should really be located in a standard .NET install location?
(2) Would it be fine to exclude them?
(3) Is there a way to get the VS Installer Project extension to simply not add them?
My end goal is to create a cross-platform (non-web) console application, so I'm exploring .NET Core right now.
In my previous .NET projects, I did all the development inside Visual Studio, but I also created a batch/MSBuild file so I could build the whole project (including setups, NuGet packages, zip files with binaries etc.) with one single click. Here's an example from a previous project.
In the end, I want to do something similar with my .NET Core test project.
But right now I'm failing at the first step: I'm unable to build it outside Visual Studio, so that the result works on another Windows machine without .NET Core installed.
(in the first step, I'm ignoring the cross-platform part - I'll be happy to get it to work on Windows)
What I have
I managed to get it to work inside Visual Studio 2015 Community Edition as follows:
create new project in Visual Studio: "New Project" ⇒ "Web" ⇒ "Console Application (Package)"
create new publish profile inside Visual Studio ("Build" ⇒ "Publish" in the menu).
This will create a PowerShell script (and an XML file with settings)
Here's my test project on GitHub.
When I do "Build" ⇒ "Publish" in the menu again, Visual Studio apparently executes the previously created PowerShell script again.
The result is slightly over 90 MB, consists of 825 files in 598 folders, and looks like this:
When I copy it on another machine (Win 7 / .NET 4 installed / .NET Core not installed), it works.
What I tried to get the same result outside Visual Studio
1. dotnet publish
This answer and this answer sound like I can use dnu publish to achieve the same result via the command line.
I understand that parts of .NET Core are still moving targets right now, so apparently dnu is now dotnet instead.
So I tried to execute dotnet publish (and created a batch file) for it:
dotnet publish "%~dp0\src\CoreTestVisualStudio" -c Release -r win7-x64 -o "%~dp0\release\cli"
The result consists of an .exe file and a bunch of DLLs, only 25 files and 1.5 MB, all in one single folder:
Obviously the .NET Core runtime is missing here, and as expected, this app crashes when I try to execute it on a machine without .NET Core installed (the same one as mentioned above).
2. The PowerShell script from the publish profile
I tried to execute the PowerShell script (which was created when I created the publish profile) outside Visual Studio, but it failed because the script expects some parameters and I don't know what to pass:
param($publishProperties, $packOutput, $nugetUrl)
There's also this line in the script:
# to learn more about this file visit http://go.microsoft.com/fwlink/?LinkId=524327
...but the link just points to the landing page of the .NET Web Development and Tools Blog.
TL;DR
What am I doing wrong?
I know that the first release of .NET Core mainly focuses on ASP.NET, but as I understood it, ASP.NET Core apps are just console apps as well, so I thought a basic console app would work now.
On the other hand, most of the console app "getting started" docs are still missing, so maybe it's just too early and dotnet publish for console apps is not finished yet?
Edit after a few days: I'm suspecting that I'm doing nothing wrong and that it's an issue in the.NET Core command line tools, so I posted it to the command line tools' issue tracker.
Problem solved!
I posted it on the issue tracker of the .NET Core command line tools, and it turned out that it was a bug in dotnet publish - it didn't bundle the C++ runtime, which is needed to execute the compiled app on a machine without .NET Core installed.
The temporary solution was to install the C++ runtime.
The "real" solution was made in a pull request three days ago, which is included in the latest installer now.
With this version, dotnet publish does bundle the C++ runtime, so the result will work on a machine without .NET Core.
For dnu:
There's an option for dnu publish called --runtime that specifies the runtime to include when publishing. You would use the full runtime name with the command, e.g.:
dnu publish --runtime dnx-clr-win-x86.1.0.0-rc1
For dotnet:
You don't need to specify the runtime or framework versions -- by default, dotnet publish will use the framework from project.json and the current runtime flavor. However, the documentation states that:
dotnet-publish command also requires certain dependencies in the project.json to work. Namely the Microsoft.NETCore.Runtime package must be referenced as a dependency in order for the command to copy the runtime files as well as the application's files to the published location.