I have a solution/team project set up in visual studio 2013 and for some time have had a working NuGet Microsoft.Bcl Async Package installed for NET Framework 4.0. Today when opening the project all of the default .NET system library references cannot be found, They just have a warning symbol next to them. I have 49 warnings when building the project all saying 'The referenced component 'System.X' could not be found. Or 'The referenced component 'Microsoft.X' could not be found. Yet references to other projects in the solution remain intact.
If it is of any significance I have been using the built in version control system to keep backups of my code and access it from my other pc with the same configuration.
Looking at the other questions on stackoverflow with similar issues people seem to point towards NuGet as potentially causing the problem but without any solution that seems to work for me. I have tried the obvious solution of removing and re-adding the reference using both the file browser and the Framework tab but neither has worked so far.
I cannot currently compile the project as I get this warning, undoubtedly caused by the missing references in the first place.
Error 31 The "EnsureBindingRedirects" task could not be loaded from the assembly C:\Users...\Visual Studio 2013\Projects\AlgorithmToolsTFVC\AlgorithmToolsSuite\AlgorithmTools\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.Tasks.dll. Could not load file or assembly 'file:///C:\Users...\Visual Studio 2013\Projects\AlgorithmToolsTFVC\AlgorithmToolsSuite\AlgorithmTools\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.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. AlgorithmTools
A possible solution: If you are seeing yellow triangles over most of your System references, edit your .csproj file (back it up just in case), scroll to the bottom of the file, and delete these lines...
<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>
Like many others, I've been using a centralized .packages folder outside of source control. This is done by having the following lines in your NuGet.Config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="..\..\..\.packages" />
</config>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
One of the steps in achieving this, is to check your project file does not use the old NuGet.targets file anymore (the only file in your .nuget solution folder should be NuGet.Config).
When NuGet thinks it should check the NuGet.targets file, and it's not there, it will fail checks to basic references too (like System.Core, WindowsBase and PresentationCore).
Update: See this related topic/answer on how to completely do away with .nuget folders in your solution! It can be set at user-profile level in your AppData.
I was able to solve this issue by first running an update on all NuGet packages in the solution and then removing and re adding references to the libraries included or overridden by the package.
Just had the same problem.
The reason for me was that all the files inside the Nuget package, suddenly become 0 byte size. I mean DLLs, nupkg file etc.
I reinstalled the package and it worked for me.
I had exactly the same problem with my project on team foundation server. I had the error saying "EnsureBindingRedirects" task could not be loaded from the assembly C:\Users...\Visual Studio..." and many warnings saying "The referenced component 'Microsoft.X"
The solution was very easy. All I had to do was copy my entire project folder into another location and it worked.
Had a similar problem. After wasting 2.5 hours trying to find a solution, I fixed it simply by opening the project in VS 2013, enabling NuGet package restore and rebuilding. Fixed immediately and now it works in VS 2015 just fine.
Just had the same issue and solved it by executing the following command in package manager console:
Update-Package -Reinstall
If you want to do this for a specific project you can use:
Update-Package -ProjectName 'ProjectNameGoesHere' -Reinstall
Related
I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)
A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.
you already checked the files app.config and packages.config, and the dotnet framework version?
Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.
I am now on the phase of refactoring madness of a big project which has a lot of legacy and unstable modules. I've decided to split the solution that currently has ALL projects (so around 20 and there will be more because of unit test projects that would surely come in next months) chained in it to make it more independent and granular.
With this approach there are modules e.g. API clients that needs to be either referenced or added in multiple solutions.
The problem is that Nuget packages are getting restored only on the solution that it was added originally for the first time. So the simplest example:
Solution A:
------ ProjectA
------ APIClient
Solution B:
------ ProjectB
------ APIClient
Since we are not including packages folder it causes problems with Nuget packages:
Clone the repo.
Open Solution B, build it and restore the Nugets for solution.
Errors with packages of ClientAPI in Solution B.
Go to Solution A build it and restore the Nugets for solution
Get back to Solution B.
Nugets are restored for ClientAPI in Solution B and errors are gone.
Is there a way to somehow:
Make the project using different path for each solution?
Maybe chain solutions in build to make Solution A always build with Solution B? But that sounds like loosing some benefits of splitting this one big solution to smaller ones.
Use any other approach to make it more granular and yet do not suffer problems with the necessity of rebuilding all? I've heard of private Nuget feeds, would that be an answer to this problem if my config allows that?
My config:
VCS: TFS with TFVC
IDE: Visual Studio Proffesional 2017
Default package management format: Packages.config
Managing Nuget packages for C# project present in multiple solutions
Thanks for you reply. I have reproduced this issue with two solutions, SolutionA with Project APIClient. And SolutionB, add the existing project APIClient in the SolutionA to the SolutionB.
Then if we restore the nuget package on the SolutionB, package in the project APIClient in the SolutionB will be restored in the \packages folder in the SolutionB folder by default rather than in the SolutionA folder.
In this case, the project APIClient still missing the .dll reference in the SolutionB, you still have to go to SolutionA and restore the nuget packages. That the reason why you got that issue.
To resolve this issue, you could add a NuGet.Config file next to the SolutionA and SolutionB with the following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="C:\Packages" />
</config>
</configuration>
So, the \packages folder not related to the solution file.
Besides, if you are interested, you can try to convert the packages.config to the packagereference for the project APIClient, with this setting, the nuget package will be saved in the global packages folder, C:\Users\<UserName>\.nuget\packages.
Hope this helps.
Why do you not add package in the solution B ?
What package mode do you use ?
If you use "Package reference" mode, you must add package information in csproj of solution B.
If you use "Package config" mode, you must add package information in package.config file of solution B.
I try to build a solution stored in an external GIT-Repository on Visual Studio Online.
It has the following steps:
1: Git Restore - Works
2: NuGet Restore - Works
3: Build - Does NOT work
My first guess when looking at the logs is that MsBuild is not looking for the Packages where NuGet had stored them.
Some Lines from NuGet Restore:
2018-03-14T21:10:11.0352862Z Completed installation of AngleSharp 0.9.9
2018-03-14T21:10:11.0353230Z Adding package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0353563Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0354972Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages' from source 'https://api.nuget.org/v3/index.json' 'Microsoft.SharePointOnline.CSOM.16.1.7317.1200' to folder 'D:\a\1\s\packages'
Some lines from MsBuild:
018-03-14T21:10:21.2105399Z PrepareForBuild:
2018-03-14T21:10:21.2105793Z Creating directory "bin\Release\".
2018-03-14T21:10:21.2424947Z Creating directory "obj\Release\".
2018-03-14T21:10:30.3569560Z ResolveAssemblyReferences:
2018-03-14T21:10:30.3570425Z Primary reference "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL".
2018-03-14T21:10:30.3670272Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
My solution/packages structure is:
....\mysolution\myproject\myproject.csproj
....\mysolution\myproject\packages.config
Current Config:
So how can I change the Nuget and/or msbuild-behavior to make this work?
(Update): To clear this up: I have this problem with every package. They all are in the packages.config, each one is downloaded from Nuget, but each one also isn't found from MsBuild
(Update2) The Commands generated are currently the following:
NUGET:
D:\a\_tool\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\AweCsomeO365\packages.config -PackagesDirectory D:\a\1\a\packages -Verbosity Detailed -NonInteractive -ConfigFile D:\a\1\Nuget\tempNuGet_22.config
MSBUILD:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "D:\a\1\s\AweCsomeO365\AweCsomeO365.csproj" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=(GUID)|SolutionDir=D:\a\1\s\AweCsomeO365"*ForwardingLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=D:\a\1\a /p:ReferencePath=D:\a\1\a\packages /p:platform="anyCPU" /p:configuration="Release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="VSTS_(GUID)_build_4_22
I replaced the GUIDs; tempNuGetConfig is something that seems to be generated by VSTS dynamically
Still. even if the log states that nuget stores the packages
Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\a\packages'
MsBuild does not seem to find them there:
For SearchPath "D:\a\1\a\packages".
2018-03-16T13:57:42.4625155Z Considered "D:\a\1\a\packages\AngleSharp.winmd", but it didn't exist.
2018-03-16T13:57:42.4625456Z Considered "D:\a\1\a\packages\AngleSharp.dll", but it didn't exist.
2018-03-16T13:57:42.4625730Z Considered "D:\a\1\a\packages\AngleSharp.exe", but it didn't exist.
VSTS-Configurationvalues:
MsBuild: /p:ReferencePath=$(Build.StagingDirectory)\packages
Nuget-DestiantionDirectory: $(Build.StagingDirectory)\packages
(update3): I have no solution file, but only a csproj-file in that repository
The issue was that inside the project there was a hintpath for the packages directing to a location that was not within the GIT-Repository (and shouldn't):
<Reference Include="AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL">
<HintPath>..\..\AweCsome365Test\packages\AngleSharp.0.9.9\lib\net45\AngleSharp.dll</HintPath>
</Reference>
My original approach was to define a target directory to NuGet and a Source Directory for MSBuild to use another location to the packages that both understand.
The issue though (as far as I understand) is, that NuGet always creates a subfolder-structure "./packages/{PackagesName}/lib/net45/{file}" and MSBuild does not look recursivly when setting "./packages" as source path.
The above is just an explanation for the future guy running into the same problem
So my solution was to mimic the local behavior for nuget and changing the output directory to match the HintPath (even if there is no "AweCsome365Test")-directory in the repository:
(I will leave this question open as this solution smells fishy. If anyone has a better solution that allows to chain nuget and msbuild without using the HintPath I am happily willing to spend my bounty on it)
I believe that your MSBuild "ReferencePath" parameter is not correct. you are telling MS Build that all your references (nuget packages and their dlls included) are going to be located at "D:\a\1\a\packages" but that is not where nuget will download and store the packages and dlls. Nuget will download and extract files into D:\a\1\a\packages\{packageName}\{version}\lib\{environment}\package.dll. I think you need to remove that last parameter (ReferencePath) from your MSBuild arguments.
I also noticed that your PackageLocation parameter is not the same as the destination for the NuGet restore task, do you need to add the "\packages" to that parameter like the destination in the restore task?
Change the nuget restore destination directory to $(Build.SourcesDirectory)\packages and remove the msbuild ReferencePath parameter.
The answers here are largely right. However it's worth noting another cause that can result in this behaviour. My toolchain was using Azure DevOps which is basically the same as Visual Studio Online, just a few years later.
Cause:
Reference your project from a different solution (cross-repo), for instance for debugging purposes
Update NuGet references in the problematic project from the external place you referenced it from
What this does is make use of the solution location for packages when the package gets installed.
For .Net core/standard projects, using Update-Package -reinstall appears to fix things. However, for .Net Framework projects, even though packages.json may get rebuilt, the <HintPath /> node in the .csproj gets left as is - with a reference to a packages folder that Azure will never create.
Simple fix:
Right click on the offending solutions locally, and choose Unload
Right click on the unloaded project, choose edit .csproj
Find any hintpaths that look like ../../OtherRepo/packages (the slash in use may vary), and change them to ../packages
Confirm the solution does build locally still
Push the changes to Azure, and cross your fingers
This approach will fix the issue caused by consolidating / updating packages from the wrong place rather than requiring a change to the build pipeline to spoof that location (which in may case, wasn't working very well either).
Due to some git project changes, when I try to build, I get an error:
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\MSTest.TestAdapter.1.1.11\build\net45\MSTest.TestAdapter.props.
The references to the project contain four missing references, two of which Microsoft.VisualStudio.TestPlatform.TestFramework, and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions which seem to be related.
The other two, in case it proves to be relevant are System, and System.Core, but they aren't causing any problems... which is weird, cause I'm definately using them.
That missing file, the one from the error message, is absolutely there.
I've tried to uninstall and reinstall both packages, but nothing seems to help.
Open the projects .csproj file with your favourite text editor and delete any references to
MSTest.TestAdapter.props.
Edit: This is safe to do so, all that happened is that you have removed the DLL but for one reason or another your project file still references it as a dependency.
I would modify #JoshuaDuxbury's answer to say: you need to clean out obsolete references to MSTest.TestAdapter.props.
In my case, I had just updated the MSTest.TestAdapter NuGet fronm 1.3.2 to 2.0.0, but apparently when I did that, Visual Studio didn't clean up my .csproj file perfectly.
So, I had to delete the superflous MSTest.TestAdapter.props highlighted in two places:
Near the top of the project file:
...and again at the bottom of the file:
Once I did that, my CI pipeline was able to build everything correctly again.
Some of you with sharp eyes may notice something funny w/the 1.3.2 of MSTest.TestAdapter shown above: it seems the path to the packages folder is off! But that would be a topic for a different thread (or maybe an alternate explanation to why your build pipeline is unhappy.. maybe just fix your path to packages).
My issue didn't occur on my development box but on the Azure Build Pipeline. I removed the offending props files as per the other answers but to no avail. Ultimately I had to add the Nuget restore step to my the Azure build pipeline and move it to the proper slot before the building:
I have no idea how I've done it but I've had the same error and I thought the files were here but they actually weren't... so anyone who has this issue double check the paths.
In my case the Packages folder was at the same level as the project file however it was looking for files in the parent directory. Nuget restore and Update-Package -reinstall
were not fixing anything.
I have recently created project on visualstudio.com, and enabled continuous build on azure. I created web api project, and created some models and api controllers. Then I deployed it online and it was cool for a good while. Then I updated all dependencies through NuGet. Build went fine on local and also app worked on my local machine. Then I checked in to tfs, and automatic deploying kicked in, with build error.
It says:
C:\a\src\HitchStopApi\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets (74): The "EnsureBindingRedirects" task could not be loaded from the assembly C:\a\src\HitchStopApi\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.Tasks.dll. Could not load file or assembly 'file:///C:\a\src\HitchStopApi\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> 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.
On my local machine build I get warning for Tests project
D:\Programming\Projects\HitchStop\HitchStopApi\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets(220,5): warning : Project must install nuget package Microsoft.Bcl.
On local I use .NET 4.5, MVC4, Entity framework 5.0...
This is somewhat of a bug and is logged in several places. Bcl.Build isn't a project required to build on TFS, so you simply need to tell TFS not to include it if it doesn't exist. To do this, open up your .csproj file (for each project that references Bcl.Build) and change the following:
<Import Project="..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets" />
to add a condition:
<Import Project="..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets')" />
Note: If you update Bcl.Build via Nuget, it will also update your project file and the following will need to be done again. Create a second copy of this and comment it out if you don't want to lose it every update/have a reference.
Related References (same issue, different manifestation):
http://social.msdn.microsoft.com/Forums/en-US/TFService/thread/7bd2e96b-552a-4897-881c-4b3682ff835e
https://connect.microsoft.com/VisualStudio/feedback/details/788981/microsoft-bcl-build-targets-causes-project-loading-to-fail
https://nuget.codeplex.com/workitem/3135
Update: Microsoft wrote an official blog on this. While the above does work in some situations, its not a guarantee. Microsoft and the NuGet team are working together on a solution, but in the meantime have provided 3 (better?) workaround options:
http://blogs.msdn.com/b/dotnet/archive/2013/06/12/nuget-package-restore-issues.aspx
Stop using package restore and check-in all package files
Explicitly run package restore before building the project
Check-in the .targets files
Your problem is described here
Solution:
1. Add dummy project (NugetHelper for example), add package.config with
<package id="Microsoft.Bcl.Build" version="1.0.6" targetFramework="net45" />
Open Menu -> Project -> ProjectDependencies and make NugetHelper to build before other projects in solution
Replace
<Import Project="..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets" />
with
<Import Project="..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets')" />
this will restore Microsoft.Bcl.Build.targets before actually loading it in your main project