I have a .NET Core 2 application and I'm trying to reference a NuGet package which contains static files and have them copied to my application similarly to how the "content" directory worked in the past.
According to the following https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html this looks to be supported under a "contentFiles" directory.
I've found the following package which looks to support the new schema:
https://www.nuget.org/packages/ContentFilesExample/
And added a reference to it by adding the following to my .csproj file:
<PackageReference Include="ContentFilesExample" Version="1.0.2" />
Now when I run dotnet restore it doesn't copy anything to my application. I've been searching through the GitHub issues but it's hard to follow what is outdated and what is supported.
I'd appreciate it if someone could let me know if this is supported and what I could possibly be doing wrong. If it's not supported please could you point me in the direction of the correct GitHub issue to follow. Thanks
With PackageReference, the files are never copied over to the project. Rather the content files live in the global packages folder as immutable entities. You can still refer to these files as if these were expanded in your project.
If you use Visual Studio 2017, you can see these as refs as shown below. You can refer to .csproj.nuget.g.props file in the obj directory to find out the details of the files refs/links.
Have you looked at NuGet pkg Microsoft.AspNetCore.StaticFiles (2.0.0) ?
Related
My Web2 solution is failing to compile because some of the packages were hosted in a different directory structure to the rest of the solution, and I deleted this structure and the corresponding "packages" folder.
I used Update-Package -reinstall
Hoping that this would fix it... however it still kicks out this error message on build:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props
Now as far as I can tell all the references should be OK, packages.config says:
<package id="Microsoft.Net.Compilers" version="1.0.0" targetFramework="net45" developmentDependency="true" />
And the directory structure exists
--Solution Dir
|-- packages
|--Microsoft.Net.Compilers.1.0.0
I tried updating the package and got version 1.3.2, but the error message remained the same, ie version 1.0.0 was missing.
Theres' clearly some reference to this floating around somewhere - but I don't know where to start looking. I'm assuming the ..\packages in the path indicates its looking for the package in the external directory location (as one up was where the original packages were)
Any ideas?
UPDATE:
I copied the packages folder back to its original location outside the solution directory and .... the issue isn't resolved. So maybe that was never the issue in the first place.
However the error message is still reporting a missing NuGet package that to all appearances is actually there.
This StackOverflow answer got me started on the right track, once I Googled the error message without the ..\ in front of the package location
https://stackoverflow.com/a/32296184/1286358
Then I had to go through and add serveral missing references - presumably because in my hacking attempts to fix the issue I had removed them then not re-referenced them.
I have found a dll that is provided via Google Code and I couldn't find it in NuGet. I want this package to be available via a NuGet install, because I want to reuse it in several packages and NuGet seems like the perfect way to do this.
https://code.google.com/p/protobuf-remote/downloads/list
Is it possible for me to generate a nupkg out of these dll's and publish it to NuGet.org? What are the legal limitations to this action?
There are a number of other users that have run into this issue. It seems like the common solution is to create an "Unofficial" package and reference that for the time being (until Google publishes their library as a NuGet). Just make sure to very clearly label the package as unofficial. See these examples.
As for the legal ramifications...
Please look through protobuf-remote license and review the distribution and derived works details. Currently the license is GNU Lesser GPL. Sorry, but you'll have to make your own call on if publishing the NuGet package would be permitted under this license. ;)
I would recommend you instead create a local NuGet package source by pointing to a file share. This can be local on your computer or on a network file share.
Also, if you don't want to update every workstation, you can update the NuGet.config file in your project to point to this source and commit that config file in your source control repository for all users to get automatically. Just note that any change to a NuGet.config file requires you to restart Visual Studio.
And FYI, take a look at how you can chain multiple NuGet.config files.
After a clean Windows reformat and installing Visual Studio 2013, trying to build a project with database-first Entity Framework edmx files yields the following error:
The "EntityDeploySplit" task could not be loaded from the assembly
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll. Could
not load file or assembly 'file:///C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll' or one
of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements Microsoft.Build.Framework.ITask.
Is there some way to install this separately? What is this assembly included with by default?
UPDATE: This also manifests itself when looking for the EntityClean task. I'm inclined to think that it checks the bin first, since another developer who was running it fine tried a clean / rebuild and then this started showing up.
I found the accepted answer to be a little confusing, below are the steps that worked for me.
Open C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets in notepad.
Alter the UsingTask elements to:
<UsingTask TaskName="EntityDeploySplit"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploy"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploySetLogicalNames"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityClean"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
I ran into this problem and was able to fix it as I have described below. Your paths and variables may be different.
I found that when my project builds it points to this target file:
C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Data.Entity.targets
That target file appears to just be a placeholder. There is an Import element, in that file, that points to $(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.targets which runs the target file located at that path. I searched registry and found that MSBuildFrameworkToolsPath is a registry entry with the value of C:\Windows\Microsoft.NET\Framework\v4.0.30319\
I went to the targets file that was referenced and search for the UsingTask element that was specified in my exception. Inside the UsingTask element, the AssemblyFile attribute was pointed to $(MSBuildBinPath)\Microsoft.Data.Entity.Build.Tasks.dll. I searched the registry and found that the MSBuildBinPath registry entry was pointed to c:\Windows\Microsoft.NET\Framework\v3.5\
I'm not sure why it was pointed to that, maybe a Framework or Visual Studio installation didn't clean it up. Finally, I changed all my UsingTask elements' AssemblyFile attributes to:
$(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.Build.Tasks.dll
I used the same variable that was in the MSBuild Bin target file.
Hope this helps.
I give a lot of credit to Andy Mahaffey for his answer, without it I would not have found what I did.
I followed along his line of research but didn't like the idea of just changing the UsingTasks' attributes. I opened up the "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets" file and I found the first thing it says after the opening Project element is this comment:
<!-- This .targets file can be used by updating Microsoft.Common.targets to
include the line below (as the last import element just before the end project tag)
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
-->
I followed it's suggestion and presto, problems solved.
I hope this helps!
TLDR
Paste the line below as the last element before the tag in the following file. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
In my case, I had accidentally created two copies of one of my .edmx files, one in a subfolder, where I didn't notice it. Once I deleted the extra one, everything was fine.
I've created new solution in Visual Studio, enable nuget package restore and got in soluition root .nuget folder which contains the following files needed to make package restore work: NuGet.exe, NuGet.config, NuGet.targets.
But I can't make nuget(as Nuget Visual Studio add-in and \.nuget\NuGet.exe as well) read setting from .\nuget\NuGet.config file - settings are still read from default %appdata%\NuGet\NuGet.config.
What have I tried.
I've tried to look where the path to NuGet.config is specified and haven't found anything like that, and nuget.exe install command that runs during build doesn't have any parameter saying like "take this nuget.config file".
Also I've removed \.nuget\NuGet.config and everything works - packages are restored during Visual Studio build and CI one.
Question.
I've got an impression that \.nuget\NuGet.config isn't used at all.
So essentially the question is: How to make .nuget\NuGet.Config file to be not ignored?
What am I doing wrong and how to do it write?
Thanks and have a nice %time_of_day% :)
Disclaimer
Everything that I've mentioned above is not a problem/issue - current nuget behavior is completely acceptable for me - I'm asking just because I'm curious and confused at the same time
I haven't tried this personally, but here is what the official Nuget 2.1 release notes say:
NuGet.config files are searched for in the following order:
.nuget\nuget.config
Recursive walk from project folder to root
Global nuget.config (%appdata%\NuGet\nuget.config)
The configurations are than applied in the reverse order, meaning that
based on the above ordering, the global nuget.config would be applied
first, followed by the discovered nuget.config files from root to
project folder, followed by .nuget
If this doesn't help I'd suggest you write more specifically what you're trying to achieve and which config settings you're changing - knowing more details about the problem may clarify the situation.
Did you point the config file that you want to use as ?
In nuget page example;
nuget config -set repositoryPath=c:\packages -configfile c:\my.config
nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\Config\VisualStudio\14.0\NuGet.Config
nuget config -set repositoryPath=c:\packages -configfile %ProgramData%\NuGet\NuGetDefaults.Config
I'm interested in creating a NuGet package for a documentation tool I'm writing. Ideally, I'd like the user to not have to configure my tool in anyway. In order to do this, I need to be able to read some settings from the Project's .csproj or .vbproj file to get the path of the Xml documentation file generated by the compiler. I also need to add a post-build step to the project.
I've looked through their documentation but I haven't seen any mention of being able to do this. Is this possible? If so, is there any documentation or examples of this available?
Using PowerShell script, you can access the rich VS DTE object model. This allows your package to do all kind of things that NuGet doesn't have specific features for. Look at this help topic for some info on using init.ps1 or install.ps1.