restore fails to find a wrapped csproj when its folder in in global.json/projects list

[abpiskunov]

When adding project references, for csproj we wrap it and add a normal project reference to xproj file, for xproj we add its subfolder to global.json/projects list.

I tried to add reference to csproj file alone and it worked well, but when i added it's subfolder 'foo' in the global.json/projects list restore started to fail to resolve it.

Project.json:

Global.json

my projects:

restore output:

ClassLibrary1's wrapped project.json:

{
"version": "1.0.0-*",
"frameworks": {
"net452": {
"wrappedProject": "../../foo/ClassLibrary1/ClassLibrary1.csproj",
"bin": {
"assembly": "../../foo/ClassLibrary1/obj/{configuration}/ClassLibrary1.dll",
"pdb": "../../foo/ClassLibrary1/obj/{configuration}/ClassLibrary1.pdb"
}
}
}
}

[muratg]

@ChengTian

[ChengTian]

Hi @abpiskunov , each element in projects of global.json should be a parent folder of your projects.

For example, you have src/WebApplication5/project.json, then src should be added to projects, instead of src/WebApplication5

You can fix it by replacing foo with . (dot, i.e. current folder).

[ChengTian]

@davidfowl , it's actually quite intuitive that I should be able to add src/MyProject to projects in global.json. Is there any specific reason that we don't support it?

[davidfowl]

it shouldn't be that big of a perf hit i guess. Verify that it doesn't

[abpiskunov]

@ChengTian isn't "foo" has same hierarchy level as "src" in your sample: foo\ClassLibrary1*.csproj and in your sample src\WebApplication5\project.json. Both of them are parent folders for projects, isn't it?

[davidfowl]

Are you looking at the csproj or the wrapped project.json

[abpiskunov]

csproj, also notice that I did not create this structure on purpose. I first created a csproj in foo folder, then added a reference to it (it was wrapped). After that I added an xproj to folder foo and added a reference to it. After that csproj became unresolved... Valid user actions leading to not some strange state...

[davidfowl]

it comes down understanding what belongs in global.json and Wei already called out the problem

[abpiskunov]

Well that is true :), if we assume an ideal user who keeps in the head all little things, he would figure it out and fix it. But the fact that we have a workflow where user does very valid things and ends up with something broken that was working a minute ago - does not really feels good.. From tooling side we also can not do anything since we don't restrict or anticipate relative project's position to each other ...

[davidfowl]

Ok lets start over:

The list of projects in global.json specify locations where projects can be searched for, not direct project locations. This means that:

{
    "projects": [
        "src",
        "test",
        "wrap",
        "foo"
    ]
}

Projects can be in:

src/{project}/project.json
test/{project}/project.json
wrap/{project}/project.json
foo/{project}/project.json

If that's fully understood, then it should never be confusing why something is shown as unresolved.

Given that base knowledge, repeat the steps you did and try to back track to see where it all went haywire.

[davidfowl]

Ok @abpiskunov showed me the issue and I think the bug is here:

https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Framework.Runtime/ProjectResolver.cs#L74

The simple repro should be:

src/Foo/project.json
test/Foo/Foo.csproj

We map all potential projects by folder name without checking for project.json as an optimization. Unfortunately it causes this ambiguity. You could ask what we should do in general if we saw 2 projects with the same name (we should probably fail). But there is no ambiguity here.

[ChengTian]

Looks like it's not easy to debug when you run into this case. So the earlier we fix it, the better (beta5?).

To eliminate ambiguous cases as many as possible, here are the two things we can do:

1. Check existence of project.json when resolving all potential projects. (Need to check performance to decide whether we want to do this.)
2. When there are two candidate project folders with exact same name, we throw error:

Ambiguity between the following two projects:
path/to/ProjectA
path/to/another/ProjectA

[davidfowl]

Check existence of project.json when resolving all potential projects. (Need to check performance to decide whether we want to do this.)

That's way too slow. I know I tested it. We'll need to do it when accessing that particular project. Store all entries up front.

[ChengTian]

Ok, we'll only do item 2 above.

[davidfowl]

@ChengTian You may not want to throw during the scan. Throw on access if there's more an than one potential folder with a project.json.

[ChengTian]

Yeah, makes sense. If we don't use the project with that ambiguous name, it does no harm and we don't care the ambiguity.