I have created a new web site using Visual Studio 2017. The target framework for this site is NetCoreApp 1.1. As this is an MVC project, it references a number of Microsoft and third-party dlls from Nuget. I also have a data project that I created as a library. It is Netstandard1.6. When I build the solution, none of the dlls from the Nuget packages are copied to the bin folder. This causes the app to crash with a FileNotFound exception when attempting to debug it. The project references are being copied correctly, so it appears to only be a problem with Nuget packages. As a workaround, I can publish the project and copy that output to the bin folder, but I shouldn't have to do that, should I?
.NET Core uses the generated .deps.json file in the output to resolve assemblies, so it avoids copying the files unnecessarily during the build.
However if some assemblies try to look for other assemblies in the output directory or the files referenced in the deps.json file cannot be accessed (e.g. testing build output in IIS), you can add this to a <PropertyGroup> element in your csproj file to cause the NuGet assemblies to be copied to the output directory:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
This 'CopyLocalLockFileAssemblies' doesn't do anything on my end. The only way I found to get the content of the 'runtime' folder in my output is to use 'Publish'. This is not a solution to locally debug an application.
Edit :
Adding the Runtime IDentifiers to the project file seems to do it for me.
Also, .NET Core 3.0 fixes the issue but it is only in Preview.
Related
I have created a .netstandard nuget package which I am using in Asp.NetCoreWebApi. When I install the nuget packages, some fonts and images that are present in a folder named 'Resources' are downloaded into the .net core project. This is not physically available in the project root, but available as a shortcut link which is denoted by small arrow icon in the solution explorer.
When I build the project, this 'Resources' folder is available in the bin\Debug folder.
Now, when I run the WebApi project, and debug, I am getting an exception which says,
"Cannot find the path \Resources\Fonts."
Why isnt my WebApi searching in the Debug folder?
How to change this ?
I have an SDK project in my solution. And i need to add a NuGet package ("customLib.net"), which provides the functionality to find the differences between files.
If you create a simple .Net Framework 4.7.2 console application and add this NuGet to it, then it will automatically download it along with all dependencies, including "customLib.redist.windows.x64". As i understand "customLib.net.dll" is an API for .net, and "customLib.dll" (which comes from "customLib.redist.windows.x64" package) is an engine itself, compiled for win-x64. The package is stored in SolutionFolder/packages. And there is a package.config file with all required references. And everything works as expected.
But if to add the same NuGet package to SDK (Class Library) project, which has the same target: .Net Framework 4.7.2, it should also download the NuGet package along with all dependencies. And it does. But it doesn't store the packages in SolutionFolder/packages folder, and there are no any package.config files. It stores them in global NuGet storage on C drive. And the problem is that when i launch the application it throws an exception in runtime:
"Unable to load DLL 'customLib': The specified module could not be found.".
And this dll doesn't exists in output folder. I solved this issue by downloading the "customLib.redist.windows.x64" NuGet package to the project, despite the fact that "customLib.net" already has a reference to this package. This is a little bit weird for me, and here are the questions:
Why, if a "customLib.net" depends on "customLib.redist.windows.x64", it does not copy dependent dll to the output folder? At the same time, the console application copies both libraries.
Why after downloading "customLib.redist.windows.x64" NuGet the "customLib.dll" file shows in my project root in Visual Studio with full path to "C:\Users\MyUsr\.nuget\packages\customLib.redist.windows.x64\1.0.1\runtimes\win-x64"?
As per the description, I can assume that you have .NET standard console application but you added the .Net core class library into it. That's why you are facing such issues.
Because in the .NET core library project, there is no package.config file and references were added directly to the csproj file. As well as packages downloaded to the user's directory, instead of the packages folder.
So, instead of adding a .Net core library, you need to add the .NET standard class library into your project
To know more about it refer to What is the difference between .NET Core and .NET Standard Class Library project types?
In the net core world, you have to invoke the publish command to bring the assemblies, referenced through nuget, into your projects output directory.
In the .NET Framework world, there is no publish command. My assumption was that msbuild always resolves the referenced nuget packages and copies the assemblies to the output directory. On my developer machine this works always.
Now we see problems that this does not happen during an automated build and colleagues started to add references with the GeneratePathProperty and do an explicit copy action with CopyToOutputDirectory. In my eyes that's wrong and error prone because transitive dependencies are not resolved automatically.
Can someone point me to a piece of msbuild documentation which explains the nuget handling?
Edit: After submitting this post I identified the real issue: MSBuild/TFSBuild does not deploy .dll 'CopyLocal=true' files if they are found in the GAC. In this case the "System.net.http.formatting" dll is in the GAC on the build server. Look here and here
After an upgrade from TFS 2012 to 2015, the build agent no longer copies the following DLLs to the drop locations. How can I identify why the build agent is not copying those files?
system.net.http.formatting, System.Web.Http.dll or System.Web.Http.WebHost.dll
Detail
We have solution with MVC projects that reference the above dlls.
The .csproj files use a hint path to reference the files in the solution /packages/... directory. I have confirmed the path is a valid: the solution has a packages directory.
Before the upgrade to TFS 2015, when building the solution, the above files are copied to the drop location. However they are not after the upgrade.
The build does not fail, however after the TFS 2015 update the target web server throws a 'file not found' error. (MVC is not and cannot be installed on the target web server)
The build utilizes a 2012 XAML Build Definition
Looking at the build log files, both reference the .dll files
CSC.exe ...
/reference:D:\B\15...\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll
The build logs shows that only the version build by TFS 2012 copies the .dll file to the drop location. The 2015 build log does not have a line similar to the following:
Copying file from "D:..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll" to "D:..\BIN\EG.WS.EZScan.Web.Intranet\System.Net.Http.Formatting.dll
The build server was not changed during the upgrade other than the re-install of the build agent. The server was not rebuilt. No components were removed or added.
The project did not update to a newer version of MVC. The projects reference version 4.0.0.0. The GACed files on the build server is version 4.0.0.0 (file version 4.0.20710.0)
What else should I look at.
Since you have upgraded to TFS 2015, it's suggested to use the new build system which is completely different from XAML build. Check: https://www.visualstudio.com/en-us/docs/build/overview
It seems you are still checking in the referenced dlls to TFS, which is not suggested. Instead, we suggest restore the packages via a package manager such as NuGet. Check "Migrating to automatic restore" at website https://docs.nuget.org/ndocs/consume-packages/package-restore#msbuild-integrated-restore
If you start to use new build system, you can simply include the Restore NuGet Packages task in the definition before any build task. Detailed information of Nuget Package Restore, please check https://docs.nuget.org/ndocs/consume-packages/package-restore
I am trying to make an (web for IIS) installer package with install shield limited edition. I added the project primary output and content files and debug symbols to the installer, the setup is built, it is installed correctly but now the problem:
Two of the main project referenced projects dlls are not properly built, meaning that an old version of that dll is built and copied in the setup. My (installed) website doesn't work with those because i changed that projects before making the installer.
If i copy the that dll's from the project manually into the installed folder it works.. . My question is : Where does Installshield get those dlls when building the setup? it shouldn't build the project again and add the new(just built) referenced dlls?
Also if i delete my temporary files from Microsoft.net folder in windows it builds correctly the setup(meaning that the dll's are built at that time). On the setup project at 'dependencies' i have marked all the projects i am using for the main project..
I am using VS 2012 and IShield limited edition 2012.
I've been including DLLs in my main project's bin\release folder in the installshield 2012 LE projects by adding them to the [INSTALLDIR] in the 'Files' section. HTH
I had the same issue today. My .NET project had a DLL inside it that the project referenced. InstallShield was building the MSI with an old version of that DLL.
Clearing the Temporary ASP.NET Files folders resolved the issue. Wasn't able to diagnose why InstallShield has this issue.
Here are the paths specifically that I cleared:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files