-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error message around "Unable to find project information" should be a little more specific inside VS #5350
Comments
Good suggestion, this message should be improved for VS scenarios. @davkean do you have any suggestions on what the ideal behavior should be for restore in VS when a project is unloaded? Should this still be an error, a warning, or ignored? How can the experience be improved for this common scenario? |
I saw this error when a project in solution A, referred to another project, part of solution B. It would help if the error message directly say - Project cannot refer a project outside the solution. |
Just found this message as well. However, in my case both projects are in the same solution, so none is referring to a project outside the solution. Perhaps there is more than one root cause for this (misleading) message? |
Same here. Just upgraded to Core 2.0, but projects are all still 1.1. Building has no errors, but I receive this message when trying to debug an ASP.NET Core 1.1 app in VS Code on Win10. I can ignore, and it will start up normally. All my projects are in the solution. |
This error can also happen in Visual Studio when the project is not in the solution as @ManfredLange mentions. See also: dotnet/project-system#2812 |
Removing the |
Just encountered the same error code (and message). As expected, having the project in question opened within the current solution did the trick. Curiously, attempting to build the project again (with the dependency unloaded, of course) after the error resulted in 'success', wherein it compiles, and the application only hits an error when it attempts to use the inaccessible project's code. Switching between debug and release results in the next compilation to throw a NU1105 again. |
I get this error message after upgrading to 15.5 on a project that is very much loaded into the solution, waiting doesn't help, clearing Nuget cache and throwing out NuGet config neither. Any other hints how to solve this? Like 15.3 and 15.4 before it the glorious 15.5 has yet again broken our build |
@bjorncoltof After you see the error, what effect does it have on the project? Does it no longer restore? |
The restore in VS fails and then the build fails with:
The restore does not give a hint on what could be wrong... |
Has "D:\GitHub\nfield-source\DotNetProg\NipoSoftware.Utilities.Azure\NipoSoftware.Utilities.Azure.csproj" been added to the solution? |
yup, that's in the solution (was there from the start) |
@emgarten This is a case of where the project |
Same error since vs 15.5. @MohsenBzm solution worked for me. |
//cc @jainaashish who is investigating this |
I'm trying to build up our solution from the inside out to see if one speific project causes this, running into this often too |
Deleting the .vs folder and restarting Visual Studio helped for me |
There could be multiple root-cause for this error, some of these are already mentioned here like:
overall, this error means that NuGet did not have restore metadata details about this project which is why it can't restore this project. But we should definitely improve this error message or may be create multiple error codes to differentiate. @bjorncoltof can you also check if your case is related to case sensitive scenario of project unique name. Just make sure project path and project reference has same casing. |
I'll check the casing tomorrow. In the meantime I recreated the solution to figure out what project causes this. In the end the new solution did not have the problem. The big difference I saw was that the old one had multiple configurations in the sln file and the new one only had debug & release. I remember reading a post by @davkean that the way msbuild detect configurations was changed, but sadly I'm unable to find it again. |
I have just had the same error after upgrading to latest version of VS2017 via the updater. Project was working fine and building with no problems even after update. However, I excluded a folder from my Core project. Went to build and got that error. I included the folder back in but the error still persists. I have even reverted the core.csproj file but cannot build the solution still!! 👎 Severity Code Description Project File Line Suppression State I have deleted the .nuget folder as sugested above. But it has not solved the issue? Any other ideas? |
Take a look into csproj files if the casing of referenced projects is identical to your windows paths. |
I've copied it exactly. And even put the full path in i.e.
I get a similar error for this. Which is
This is the section in the .targets file it's referring to? Does anything look wrong with this?
Still same issue. A temporary workaround is to remove the ProjectReference and just reference the project DLL directly in the debug folder. But like I say, this is temporary until this is fixed in next VS release. I have looked through all my commits and nothing has changed in the csproj files or .sln files. Which is why it's so confusing. |
I see the casing problem. Src one time in lower case and one starting with uppercase. |
But this is a VS issue as when you reference a project, it's done like this
So VS decides if it's Src or src |
Actually! Yes you are right. The Web.Ui project reference in the .sln file was still referenced as Src so I changed to lowercase like all others and the file system and it's working again 👍 Thanks for your help. |
It was a casing issue for me too. This sensitivity is not usual for Windows, but I guess there were interoperability choices at play when deciding it should behave this way. Nevertheless, would it be possible to make the error message more descriptive? The tool should definitely discern between "damaged file" and "missing file" and ideally, it should notice whether the "missing file" is actually present at path with different case. |
I've run into this case sensitivity issue several times when converting full framework projects and solutions to the new csproj format supported in VS 2017. I've now gotten used to seeing the not-really-helpful errors and remembering to check the case of the paths. |
Same issue for me after upgrading to the latest VS2017. I had to update my .sln file and all my .csproj files to fix all the casing issues. After that, these errors went away and I could build again. |
I too wasted some time (which I'll never get back) with this error message and the underlying bug. The issue for me was a difference in case in the Error message was:
The line in the solution file was:
Changing the line in the solution file to:
(which matches the path on disk) solved the problem. Then I had to find csproj references that include the lower-case directory name, and fix those up too. This is a new issue, seems to have started with VS 2017 15.5.x. It seems to me that it's really bad form to introduce case-sensitivity in minor version or bugfix release. |
Prevented build after a new Clone (re: NuGet/Home#5350)
Prevented build after a new Clone (re: NuGet/Home#5350)
@johncrim Thank you for posting this here, I had the same issue with casing in a solution file. |
@johncrim @jeroenlandheer casing issue in solution file has been fixed with latest VS 2017 15.6 preview bits. Please try those and let us know if you still see that issue. |
@jainaashish I've solved it by hand-editing the sln file, I'm unable to use preview/pre-releases versions here on this project. (Company policy :( ) |
removing project from the solution and adding it back resolved this issue for me |
After the work various teams have done internally at Microsoft to generate SLN files "on the fly" from dependency analysis of csproj files I'm a bit surprised VS hasn't incorporated some of that utility into devenv directly. It'd be awesome if Vs would just create a new SLN automatically if one isn't in the directory and automatically add in the projects through the chain. Our particular build system frowns on checked-in SLN files. |
.Error message is updated and merged into dev but still keeping it open to make a call for 4.9 release. |
merged for 4.9.0-preview4 branch |
When Project Of Solution A Refer a Project Of Solution B I've solve the problem building solution B and then solution A works succefull again Thanks All. |
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. |
this one works like a charm. thank you |
I opened a solution that I'd previously unloaded a project, and it stated the following about that project:
This should be more specific to the actual problem, ie "the project is unloaded".
The text was updated successfully, but these errors were encountered: