I've implemented SlowCheetah in a web project. I'm running NuGet v2.7, but still using Enable Package Restore. I run a build workflow in AntHillPro that first runs NuGet Package Restore then MSBuild on the solution. The Package Restore steps indicates it is successfully reinstalling SLowCheetah, but the MSBuild step shows no execution of the transform process for config files other than web.config. I tried switching to the v2.7 NuGet Command Line Restore but that changed nothing. I'm back with Enable Package Restore but I have no idea where to go from here and how to debug this problem. I'd swear it was working correctly a couple of weeks ago. Not sure if I have a SlowCheetah problem or a NuGet problem. How do I debug this? Any help is greatly appreciated.
I had a similar problem and it turned out that during a merge, in my csproj file, the PropertyGroup (labelled SlowCheetah) went down the Import element.
It should be like this
<PropertyGroup Label="SlowCheetah">
<SlowCheetahToolsPath>$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\..\packages\SlowCheetah.2.5.10.3\tools\))</SlowCheetahToolsPath>
<SlowCheetah_EnableImportFromNuGet Condition=" '$(SC_EnableImportFromNuGet)'=='' ">true</SlowCheetah_EnableImportFromNuGet>
<SlowCheetah_NuGetImportPath Condition=" '$(SlowCheetah_NuGetImportPath)'=='' ">$([System.IO.Path]::GetFullPath( $(MSBuildProjectDirectory)\Properties\SlowCheetah\SlowCheetah.Transforms.targets ))</SlowCheetah_NuGetImportPath>
<SlowCheetahTargets Condition=" '$(SlowCheetah_EnableImportFromNuGet)'=='true' and Exists('$(SlowCheetah_NuGetImportPath)') ">$(SlowCheetah_NuGetImportPath)</SlowCheetahTargets>
</PropertyGroup>
Then
<Import Project="$(SlowCheetahTargets)" Condition="Exists('$(SlowCheetahTargets)')" Label="SlowCheetah" />
Here is why the order of elements is important in a build file. Hope it helps
Related
The scenario
You add a nuget package, which in turn injects <Import .../> statement into your csproj file which references a targets or props file from the package itself.
This works fine when building the code in Visual Studio, but fails miserably when building the same solution with msbuild.
The root cause
There are several. First, the logic to restore the packages is executed by the VS itself outside of the build proper. We can solve it by importing Nuget.targets which would run the RestorePackage target before the build. Check.
But the second problem is more serious. The Import statements importing targets/props from the packages can only be resolved after the packages are restored. Meaning restoring the packages cannot be part of the build. It must happen before the msbuild is given the solution to build. Yes, Visual Studio does it already, but I do not use Visual Studio on my Gated Check-In or CI server. I need it to work with msbuild.
What one can do?
As far as I understand, I need to be able to run the same logic VS does only on the command line. I.e. identify the packages and restore them before running msbuild. But devil is in details. Cannot be I am the first one to face this problem.
How do you do it?
Found the answer in this blog post - http://sedodream.com/2013/06/06/HowToSimplifyShippingBuildUpdatesInANuGetPackage.aspx
Following this blog I have created before.MySolutionName.sln.targets file with the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Restore">
<Target Name="Restore" BeforeTargets="Build">
<Exec Command=".nuget\nuget.exe restore $(MSBuildProjectName)" LogStandardErrorAsError="true" />
</Target>
</Project>
Now all the packages in the solution are restored before the build.
Thank you, Sayed Ibrahim Hashimi.
All of a sudden, I am getting the following errors for 3 projects in a solution:
Error NU1105 Unable to find project information for 'C:\code\example\src\libs\example.I18n\example.I18n.csproj'.
The project file may be invalid or missing targets required for restore.
The only thing that has changed in the project is a couple of DB changes, but I never had any issues in the past. The only other thing is that I updated to Visual Studio 2017 15.5. Could that cause issues?
I have tried removing and recloning the solution from source control, but still getting errors. No problems on my colleagues' machines, so it must be something local.
Example of one of the .csproj files if this helps:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
<AssemblyName>Example.I18n</AssemblyName>
<PackageId>Example.I18n</PackageId>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
<PackageReference Include="MessageFormat" Version="1.0.1" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net452' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
I also got the same after upgrading to version 15.6 of Visual Studio 2017.
Closing VS and deleting the .vs folder fixed it for me.
For me, the casing of the project file on disk did not match the casing in the solution file.
Say I had a solution with LibraryA.csproj and LibraryB.csproj, where LibraryB.csproj has a reference to LibraryA.csproj. Having an incorrect casing for LibraryA.csproj in the solution file would cause NU1105 when building LibraryB.csproj:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "LibraryA", "LibraryA\Librarya.csproj", "{24DEBB3B-762A-491D-8B83-6D078C0B30C0}"
I started seeing this problem after upgrading to version 15.5 of Visual Studio 2017. I did not encounter this problem with version 15.4.5.
I had this problem and I just followed what the error message recommends inside VS:
to restore the solution.
So I opened a command line or package manager console, chdir into the directory with the solution (.sln) file and just issued
C:> dotnet restore .\mySolution.sln
Problem was fixed.
This error message will also occur if a referenced project is not included in the solution. I encountered this problem today, and I found the fix here.
I encountered this error when having a duplicate reference to a project.
<ProjectReference Include="..\ProjectA.csproj" />
<ProjectReference Include="..\ProjectA.csproj" />
Removing the duplicate reference resolved the error.
What worked for me was to
Remove the offending project
Build the solution
Re-add the project.
Seems that some projects were removed from solution file (don't know why). Fixed by undoing these solution file changes
I have next project structure (.Net Core projects):
../classLib
../../../webProject1
../../../webProject2
../../myWebProjects.sln
webProject1 and webProject2 reference classLib as project itself (not as .dll). When I opened my solution in VS 2019 and tried to build I got identical error NU1105: Unable to find project information for '../classLib.csproj'. error.
Before build depended projects you need to restore there dependency. What I did, just add
next Target to my webProject1.csproj and webProject2.csprojfiles.
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">
<Exec Command="dotnet restore" />
</Target>
Open powershell and running restore command solved my issue.
dotnet restore Sample.sln
I correct this error by simply running the clean solution option.
Right click the solution in the solution explorer and choose clean solution.
This is insane, i tried all this:
updated VS. manually deleted all bin folders, run dotnet restore, clean rebuild nothing works
solution: finally i unload all the projects and start reloading them into solution, one by one in the order they show dependency errors. then the last one just cascade fixes everything. No idea what was wrong
I recently came across Error NU1105 while using JetBrains Rider on Linux. So this involves Mono and the MSBuild version that comes with it.
It turns out this was being caused by my solution files being in a directory that was a symbolic link to another directory. I believe MSBuild was dereferencing the linked directory and instead referencing the source directory. This makes some of the referenced paths completely different, even though they are the exact same files, case, everything else. Opening the solution from the original location works perfectly now for me.
Reload the project which causes the problem, this will fix the issue,
As mentioned in the following link :
https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1105
This happend to me when I had files with names exceeding OS's max path limit. Check your names ;)
In my case I did it and it worked for me
goto Tools/CommandLine/Developer Command Prompt or Developer Powershell
type this command and Enter "dotnet restore".
Build your solution
That's all
Just use: "dotnet restore MySolution.sln",
Where MySolution.sln is your solution.
I was getting this error error NU1105: Unable to find project information for 'C:\folder2\project1.csproj'.
but project1 that I had as part of the solution was located in C:\folder1\project1.csproj (it was also there in c:\folder2\project1.csproj too but not part of the solution, so it was confusing)
Once I changed the reference to the correct location of the project it worked.
After spending 3 hours, trying out numerous solutions, what worked for me is that I had to undo my root solution sln file...some of the project references were removed..not sure how.
I've been wrestling with NuGet for a few days now and I'm turning to StackOverflow in frustration - hopefully someone here can be kind enough to point me in the right direction.
I've used NuGet several times for simple one-man pet projects, but this is the first time I've used it for something I really care about and want to have fully continuous builds, etc. I'm trying to create a simple NAnt build script to get the source for Git, ensure the external dependencies have been brought down, compile, and run tests - vanilla CI.
I originally went down the path of trying to get solution restore working, but it just didn't work or I didn't how it worked. Visual Studio is not on the build server and will not be installed there - that is not an option. As an aside, I couldn't get solution restore to work just with two developers (one trying to bring down the source fresh and build cleanly). I'm assuming it's because "allow solution restore" must be turned on everywhere (and is not by default). I punted on that approach before I got to the bottom of it - frankly, having my package manager so tightly coupled to the IDE makes me uncomfortable and was hoping I could do it another way. The package managers I'm used to using are simple command line tools - the CI build script invokes it on build, and developers do it on demand. I've spent the last two hours trying to get this working with the last 30 minutes in the NuGet source code. I feel like I'm fighting the tool and need to reboot.
Does anyone have any examples of the best to use NuGet in a multi-developer + CI scenario? This is what I want:
Any and all developers can get the source and run the tests in 3 or
less clicks (preferably 1). If the binaries are not present locally, that will be JIT fetched. If they are there, they will be updated if necessary, etc. This would ideally not even require NuGet to be installed (i.e. NuGet.exe would need to be in my repo).
Do #1 via a CI server like Jenkins, TeamCity, etc. (preferably using the same script)
If its not overly fighting the tool, I would like to have all this disconnected from Visual Studio with a single packages.config file and all binaries dumped into a single Lib folder in the root of the repo.
Any pointers would be very much appreciated.
Below, how I think you can achieve each your requisites:
You need to "Enable NuGet Package Restore" in your solution: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
As #alexander-doroshenko mentioned for TeamCity you can use Nuget Installer: http://confluence.jetbrains.com/display/TCD7/NuGet+Installer, but if you want a script to run in Jenkins, try this (works at TC too, as a command line step) for each project:
nuget.exe install "[Project folder]/packages.config" -source "" -solutionDir "" -OutputDirectory "packages"
This requisite will be done by item 1 and 2.
TeamCity has a build step for that, called "NuGet Installer", it fetch required packages from .sln file and download the locally. It does not require Visual Studio to run.
Read more about it here: http://confluence.jetbrains.com/display/TCD7/NuGet+Installer
There are several different solutions for integrating NuGet into your build process depending on how much integration you require. In our case we wanted to use NuGet as package manager and allow developers to build their solutions even if they haven't got NuGet installed on their machine. For that to work we enabled package restore which adds the NuGet binaries to your solution folder and updates the project files. Note that NuGet doesn't always do the update of the project files correctly. In our case we found that some project files got updated but others didn't. To verify that the project was updated you will need to open the project file as XML file. To achieve this load the solution and right click the project in question and select unload project. Then right click the project again and select edit [PROJECT_NAME]. In the project file you should see
A RestorePackages property in the first propertygroup. This property should have the value true
An import statement at the very end of the project file. This import statement should point to the 'NuGet.targets file that accompanies the NuGet binary.
Below is an example of one of our project files (heavily edited)
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SolutionDir Condition="'$(SolutionDir)' == '' or '$(SolutionDir)' == '*undefined*'">$(MSBuildProjectDirectory)\..</SolutionDir>
<ProjectGuid>{8B467882-7574-41B2-B3A8-2F34DA84BE82}</ProjectGuid>
<OutputType>Library</OutputType>
<RootNamespace>MyCompany.MyNamespace</RootNamespace>
<AssemblyName>MyCompany.MyNamespace</AssemblyName>
<!-- Allow NuGet to restore the packages if they are missing -->
<RestorePackages>true</RestorePackages>
</PropertyGroup>
<Import Project="$(SolutionDir)\BaseConfiguration.targets" />
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core" />
</ItemGroup>
<ItemGroup>
<Compile Include="MyClass.cs" />
<!--
.... MANY MORE FILES HERE
-->
</ItemGroup>
<!-- Import the Nuget.targets file which integrates NuGet in the build process -->
<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
The next step you'll need to take is to provide a solution level NuGet configuration file in which you'll indicate where the packages need to be 'installed' and what the URL of the package repository is. In our case the solution directory structure looks like:
(D) root
(D) build
(D) packages
(D) source
(D) .nuget
NuGet.config
NuGet.exe
NuGet.targets
(D) MyCoolProject
MyCoolProject.csproj
MyCoolProject.sln
(D) templates
NuGet.Config
Where (D) indicates a directory.
The NuGet.config file contains the following configuration settings.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
<config>
<add key="repositorypath" value="packages" />
</config>
<packageSources>
<add key="OurPackageServer" value="PACKAGE_SERVER_ADDRESS" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
This configuration file indicates that package restore is enabled, that the repository path (where the packages are placed) is the packages directory and which package sources are active.
By placing a NuGet.config file in the root directory we can use the hierarchical configuration option with NuGet. This allows the individual solutions to override computer specific configurations. The other benefit is that this way we don't need to have NuGet installed on the build server (because the executable and the configurations are in the repository).
With this setup developers can build the solution from Visual Studio. The build should work fine on developers machines even if they don't have NuGet installed. Note however that they won't be able to add packages to a project without having NuGet installed in visual studio.
On the build server you can simply use MsBuild to build the solution which will automatically download the packages from your package repository. Visual Studio is not required to be installed on the build machine for that (just the .NET framework of your choice).
I added the recent nuget package restore feature to a solution using 'Enable NuGet Package Restore':
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
However it broke my build server and I didn't have the time to fix it, so I wanted to remove it. There's no option for that as far as I know, so I removed the following line manually from all my *.csproj files:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
The problem now is that every time my *.csproj files are checked out or open my solution, the line is automatically added again, breaking my build if I accidentally check it in :(
Any ideas how I can remove it permanently?
UPDATE: despite the answer below it still keeps coming back when opening the solution, anyone with the same problem?
I didn't look very well, there's another property added to the project files:
<RestorePackages>true</RestorePackages>
Just have to remove this as well as all these lines manually from all *.csproj files:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
UPDATE:
Turns out it's a persistent little bugger, if you're manually editing your project files, make sure to close the solution and delete all the lines from the project at once, otherwise they're just added again once the project reloads...
UPDATE2:
Delete the .nuget folder from the solution root too
UPDATE3:
A later version of NuGet adds another section that you need to remove:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
Update4
Inside the NuGet.Targets located in the .nuget folder, there is another section that gets added to new projects... switch it to false.
<!-- We need to ensure packages are restored prior to assembly resolve -->
<BuildDependsOn Condition="$(RestorePackages) == 'false'">
RestorePackages;
$(BuildDependsOn);
</BuildDependsOn>
To disable Nuget Package Restore:
Delete .nuget folder
Remove specific lines from all .csproj files
Lines to remove:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
<RestorePackages>true</RestorePackages>
Note: Make sure you do all changes in one go before reloading solution or else it will add them back.
This is based on the following article:
http://bartwullems.blogspot.no/2012/08/disable-nuget-package-restore.html
Also, you might want to double-check that this option is disabled:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
Isn't it this setting here?
Options... -> Nuget Package Manager -> [uncheck] Allow Nuget to download missing packages
I'm using Visual Studio Professional + Resharper 8.2
Solutions currently using MSBuild-Integrated package restore can be migrated to Automatic Package Restore. From what I understand, this should help those who are encountering CI build issues. (Please correct me if I am mistaken).
Please refer to the document on the nuget website: Migrating MSBuild-Integrated solutions to use Automatic Package Restore at http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore
There is information there for converting with and without TFS.
David Ebbo also posted some information at http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
We actually have a blog post about it and at the end of the post a powershell script was mentioned to help with the migration.
http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore
NuGet has a blog post about migrating to automatic package restore:
http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore
There is a powershell script referenced in the blog post that will take care of removing the necessary lines automatically (and recursively):
https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/migrateToAutomaticPackageRestore.ps1
Offering a Disable NuGet Package Restore option directly is marked as Won't Fix:
https://nuget.codeplex.com/workitem/1883
I had the same issue. What I ended up doing:
1) go into each project .csproj file in the solution, open it in notepad then removed the portion of the xml and saved.
2)Then I removed the all of the package.config files in the entire solution.
3)Then I had to remove the .nuget and package folders.
At this point, I had a completely NuGet free solution.
4)Then I manually referenced any needed DLLs and hit compile and the solution ran like a champ without the NuGet packages being needed.
I followed the accepted solution to no avail using 2012. This did work though,
Completely close the VS
Update the <RestorePackages>true</RestorePackages> to <RestorePackages>false</RestorePackages> and delete the <Import Project="$(SolutionDir)\.nuget\nuget.targets" /> line
Also renamed the nuget.exe to nuget.exe.NotExe
For anyone still needing to clean up a project using the old style NuGet package restore, the IFix tool available here automates the process.
Just run the installer (IFix will be added to PATH) and then run the following:
IFix nugetrestore --fix
You can run it in check mode first to see what it will clean up:
IFix nugetrestore --check
Go to your solution directory where you have [$(SolutionDir)\.nuget\nuget.targets]
.nuget folder and nuget.targets file under it delete the folder,
and change remove lines from your csproj for once last time.
The problem won't come back to bug you again.
Remove the packages.config file within your solution.
I accidentally enabled this "package restore" option while opening my project in VS2012 RC and started getting errors that looked something like:
"Error 1 Unable to locate 'C:\FolderX\SomeProject.nuget\nuget.exe'"
To fix the error I followed the above instructions, opened open each project file in notepad and removed that RestorePackage line.
I was able to resolve this issue by taking these steps:
1) make sure you take a backup of all your current checked-out files changes.
2) physically delete the solution folder from your C:\ (path that is mapped to TFS).
3) get latest from TFS for your solution.
4) copy (if any) your changes from the backup you took in step-1.
hope that helps !
I ran into the exact same problem and tried to remove all .nuget and RestorePackage tags from the project files but one project just wouldn't reload not matter how thoroughly I examined it for .nuget and RestorePackages tags. I guess there's some hidden references to this somewhere.
In the end it was easier to just copy the files and create a new project and import it to the solution.
Nuget sucks. Just remove nugets and remove or comment package elements from packages.config in root directory of the projects where this is a problem. Use direct references into some lib folder instead.
<?xml version="1.0" encoding="utf-8"?>
<packages>
<!--<package id="EntityFramework" version="6.0.2" targetFramework="net45" />-->
</packages>
I'm trying to start taking advantage of the MSBuild Community Tasks so right after installing the .msi package I've imported MSBuild.Community.targets within the <Project> element this way:
<Import Project="lib\MSBuild.Community.Tasks.targets" />
Interestingly I've noticed such file have a reference to the local installation path in MSBuildExtensionsPath and given that in lieu of keeping code dependencies as clean as possible I'm willing to pay the overhead of distributing/versioning them with every project, I was wondering if is it possible to sort of override the default/installation location with a project-relative one in the .cproj file?
The actual layout would be like:
Dotnet.Samples.Foobar
\src
Foobar.cs
\lib
MSBuild.Community.Tasks.targets
MSBuild.Community.Tasks.dll
Any guidance will be sincerely appreciated. Thanks much in advace for any suggestion you might want to share.
In MSBuild.Community.Tasks.targets specified the path to the dll.
<PropertyGroup>
<MSBuildCommunityTasksPath Condition="'$(MSBuildCommunityTasksPath)' == ''">$(MSBuildExtensionsPath)\MSBuildCommunityTasks</MSBuildCommunityTasksPath>
<MSBuildCommunityTasksLib>$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.dll</MSBuildCommunityTasksLib>
</PropertyGroup>
You can override the path in the project.
<PropertyGroup>
<MSBuildCommunityTasksPath>lib</MSBuildCommunityTasksPath>
</PropertyGroup>
And leave import the same:
<Import Project="lib\MSBuild.Community.Tasks.targets" />