Skip to content
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

Building multiple msbuild projects which inherit the same projects #1333

Open
pieterbrandsen opened this issue Apr 30, 2024 · 3 comments
Open

Comments

@pieterbrandsen
Copy link

pieterbrandsen commented Apr 30, 2024

Hi, if I would do the case I listed in the title I get a issue where Build specification 'PATH\Components\X\X.csproj' is owned by two modules: 'Y' and 'Z' To resolve the issue, remove ownership for module configuration files at 'PATH\Components\Y' or at 'PATH\Components\Z

Is there any way to get around this error without putting all my other 80 projects into one fileNameEntryPoints array which still builds each project each change.

Any help would be appreciated!

    resolvers: [
        {
            kind: "MsBuild",
            root: d`Components/Y`,
            moduleName: "Y",
            fileNameEntryPoints: [r`Y.csproj`]
        },
        {
            kind: "MsBuild",
            root: d`Components/Z`,
            moduleName: "Z",
            fileNameEntryPoints: [r`Z.csproj`]
        }
     ]
});
@smera
Copy link
Member

smera commented May 1, 2024

Hi pieterbrandsen,
Modules are a logical construct in BuildXL that can group units of work (pips). By design they define a partition of the pip space. The error you are seeing is saying that you are defining modules that overlap in terms of the work they schedule. In this case this seems to be about project X being shared (likely as a dependency) between Y and Z.
If you are trying to build a set of MSBuild projects, I wouldn't recommend splitting them into multiple modules (unless, for example, you are trying to stitch together two repositories into the same build). You can pass a list of projects to fileNameEntryPoints (or a solution file that includes them, if that's available) and put them under the same module.
Using a single module for a set of projects (vs multiple ones) doesn't have any effect in terms of cache hits, which your comment seems to imply. If you are not getting hits when you expect them, I suggest you use the cache miss analysis feature to understand the root cause.

Thanks,
Serge.

@HelcioM
Copy link

HelcioM commented May 7, 2024

Hello everyone here! Apologies but I couldn't find any other way to contact any member of support for the usage of Microsoft(TM) \BuildXL usage with batch scripts. I have batch scripts running msbuild.exe and wondering if I could find a sample somewhere I could study?
Many thanks and kind regards, Helcio

@smera
Copy link
Member

smera commented May 15, 2024

Hello @HelcioM,
Not sure if I completely understand your scenario. Do you have scripts orchestrated by MSBuild, or scripts that call MSBuild? For the first case, you shouldn't need to do anything specific, MSBuild should coordinate the scripts as it does with any other tool. And if you want to put BuildXL on top of MSBuild, using the MSBuild resolver should be the way to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants