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.

Sign up for GitHub

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

Jump to bottom

Reading and parsing Visual Studio Solution file and project files #115

Closed
Dirkster99 opened this issue Jun 11, 2015 · 1 comment
Closed

Reading and parsing Visual Studio Solution file and project files #115

Dirkster99 opened this issue Jun 11, 2015 · 1 comment
Labels
triaged

Comments

@Dirkster99
Copy link

I am looking for a way to read and parse Visual Studio Solution file and project files in C#.

Is this possible in with MSBUILD project. Which part of the API is relevant for this? Is there a sample to get me started with this? I am primarily interested in finding all files that are referenced via solution/project files.
@aolszowka
Copy link

In the past I've modified Project files (csproj) using the Project Class (https://msdn.microsoft.com/en-us/library/microsoft.build.buildengine.project%28v=vs.110%29.aspx) although the latest on MSDN seems to mark this API as obsolete.

The API wasn't well documented when I looked at it in the past but is pretty straight forward. The example you're looking for can be extracted from this example https://msdn.microsoft.com/en-us/library/microsoft.build.buildengine.project.propertygroups%28v=vs.110%29.aspx

radical added a commit to radical/msbuild that referenced this issue Jul 23, 2019
@radical
[mono] Update bundled SDKs from cli branch 'release/2.1.8xx' (dotnet#115
5ffd8b1 
)

cli commit: aa8e8a1

Microsoft.NET.Build.Extensions          : 2.1.800-preview-64229-01
Microsoft.NET.Sdk                       : 2.1.800-preview-64229-01

NuGet.Build.Tasks                       : 5.2.0-rtm.6067
NuGet.Build.Tasks.Pack                  : 5.2.0-rtm.6067

Versions from:
https://github.com/dotnet/cli/blob/aa8e8a130a45c3fa87c2050aa47739425847d9ff/build/DependencyVersions.props
radical added a commit to radical/msbuild that referenced this issue Aug 14, 2019
@radical
[mono] Fetch SDKs, nuget build tasks etc at build time
adbbd8a 
Earlier, we were bundling dotnet SDKs, resolvers, nuget build tasks etc
in the repo itself, which were then installed with mono/msbuild. This is
done to support the scenario where the user might be running
mono/msbuild with no dotnet sdk installed.

These bits were added manually by getting the appropriate versions,
fetching the nugets and adding them to the repo. For example:

```
commit 5ffd8b1
Author: Ankit Jain <radical@gmail.com>
Date:   Tue Jul 2 17:51:39 2019 -0400

    [mono] Update bundled SDKs from cli branch 'release/2.1.8xx' (dotnet#115)

    cli commit: aa8e8a1

    Microsoft.NET.Build.Extensions          : 2.1.800-preview-64229-01
    Microsoft.NET.Sdk                       : 2.1.800-preview-64229-01

    NuGet.Build.Tasks                       : 5.2.0-rtm.6067
    NuGet.Build.Tasks.Pack                  : 5.2.0-rtm.6067

    Versions from:
    https://github.com/dotnet/cli/blob/aa8e8a130a45c3fa87c2050aa47739425847d9ff/build/DependencyVersions.props
```

This makes automated and frequent insertions/updates of all these bits,
very difficult and cumbersome. Instead, now we switch to having a
msbuild props file with the nuget versions for the various bits, which
are fetched before the build starts.

Also, we split out the parts that need to be installed over a regular
msbuild installation for mono, but are not fetched at build time - eg.
`Xamarin.IoT.Sdk`, and are available in `mono/layout`.

The versions can be updated in `mono/build/DotNetBitsVersions.props`,
and the nuget sources can be updated in
`mono/build/RestoreSourcesOverrides.props`.

New directory structure:

- `mono/layout/msbuild-bin`: contents of this are copied over to the
  msbuild bin dir
- `mono/layout/ExtensionsPath`: contents are copied to
  MSBuildExtensionsPath, which maps to `$mono_prefix/lib/mono/xbuild`
- `mono/layout/ExtensionsPath-ToolsVersion`: contents are copied to
  `$mono_prefix/lib/mono/xbuild/Current`

The fetched sdks etc are copied to:

- `mono/dotnet-overlay` which follows similar subdirectory structure as
  `mono/layout`. And the contents are also copied over to the mono
  installation.
radical added a commit to radical/msbuild that referenced this issue Aug 14, 2019
@radical
[mono] Fetch SDKs, nuget build tasks etc at build time
23bf293 
Earlier, we were bundling dotnet SDKs, resolvers, nuget build tasks etc
in the repo itself, which were then installed with mono/msbuild. This is
done to support the scenario where the user might be running
mono/msbuild with no dotnet sdk installed.

These bits were added manually by getting the appropriate versions,
fetching the nugets and adding them to the repo. For example:

```
commit 5ffd8b1
Author: Ankit Jain <radical@gmail.com>
Date:   Tue Jul 2 17:51:39 2019 -0400

    [mono] Update bundled SDKs from cli branch 'release/2.1.8xx' (dotnet#115)

    cli commit: aa8e8a1

    Microsoft.NET.Build.Extensions          : 2.1.800-preview-64229-01
    Microsoft.NET.Sdk                       : 2.1.800-preview-64229-01

    NuGet.Build.Tasks                       : 5.2.0-rtm.6067
    NuGet.Build.Tasks.Pack                  : 5.2.0-rtm.6067

    Versions from:
    https://github.com/dotnet/cli/blob/aa8e8a130a45c3fa87c2050aa47739425847d9ff/build/DependencyVersions.props
```

This makes automated and frequent insertions/updates of all these bits,
very difficult and cumbersome. Instead, now we switch to having a
msbuild props file with the nuget versions for the various bits, which
are fetched before the build starts.

Also, we split out the parts that need to be installed over a regular
msbuild installation for mono, but are not fetched at build time - eg.
`Xamarin.IoT.Sdk`, and are available in `mono/layout`.

The versions can be updated in `mono/build/DotNetBitsVersions.props`,
and the nuget sources can be updated in
`mono/build/RestoreSourcesOverrides.props`.

New directory structure:

- `mono/layout/msbuild-bin`: contents of this are copied over to the
  msbuild bin dir
- `mono/layout/ExtensionsPath`: contents are copied to
  MSBuildExtensionsPath, which maps to `$mono_prefix/lib/mono/xbuild`
- `mono/layout/ExtensionsPath-ToolsVersion`: contents are copied to
  `$mono_prefix/lib/mono/xbuild/Current`

The fetched sdks etc are copied to:

- `mono/dotnet-overlay` which follows similar subdirectory structure as
  `mono/layout`. And the contents are also copied over to the mono
  installation.
radical added a commit to radical/msbuild that referenced this issue Aug 22, 2019
@radical
[mono] Fetch SDKs, nuget build tasks etc at build time
861219d 
Earlier, we were bundling dotnet SDKs, resolvers, nuget build tasks etc
in the repo itself, which were then installed with mono/msbuild. This is
done to support the scenario where the user might be running
mono/msbuild with no dotnet sdk installed.

These bits were added manually by getting the appropriate versions,
fetching the nugets and adding them to the repo. For example:

```
commit 5ffd8b1
Author: Ankit Jain <radical@gmail.com>
Date:   Tue Jul 2 17:51:39 2019 -0400

    [mono] Update bundled SDKs from cli branch 'release/2.1.8xx' (dotnet#115)

    cli commit: aa8e8a1

    Microsoft.NET.Build.Extensions          : 2.1.800-preview-64229-01
    Microsoft.NET.Sdk                       : 2.1.800-preview-64229-01

    NuGet.Build.Tasks                       : 5.2.0-rtm.6067
    NuGet.Build.Tasks.Pack                  : 5.2.0-rtm.6067

    Versions from:
    https://github.com/dotnet/cli/blob/aa8e8a130a45c3fa87c2050aa47739425847d9ff/build/DependencyVersions.props
```

This makes automated and frequent insertions/updates of all these bits,
very difficult and cumbersome. Instead, now we switch to having a
msbuild props file with the nuget versions for the various bits, which
are fetched before the build starts.

Also, we split out the parts that need to be installed over a regular
msbuild installation for mono, but are not fetched at build time - eg.
`Xamarin.IoT.Sdk`, and are available in `mono/layout`.

The versions can be updated in `mono/build/DotNetBitsVersions.props`,
and the nuget sources can be updated in
`mono/build/RestoreSourcesOverrides.props`.

New directory structure:

- `mono/layout/msbuild-bin`: contents of this are copied over to the
  msbuild bin dir
- `mono/layout/ExtensionsPath`: contents are copied to
  MSBuildExtensionsPath, which maps to `$mono_prefix/lib/mono/xbuild`
- `mono/layout/ExtensionsPath-ToolsVersion`: contents are copied to
  `$mono_prefix/lib/mono/xbuild/Current`

The fetched sdks etc are copied to:

- `mono/dotnet-overlay` which follows similar subdirectory structure as
  `mono/layout`. And the contents are also copied over to the mono
  installation.

(cherry picked from commit 23bf293)
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
triaged
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Dirkster99 @aolszowka @AR-May