Looking for a tool...
-
Sorry to post here, but I kept getting an error when posting a Question... I need a tool that can examine a Visual Studio project, and then spit out metadata - things like: - version of MS Build - Target .NET version - list of packages/dependencies/etc. I can build this, but if something already exists that would be preferable. Ideally it can scan projects in an Organization's Azure DevOps repositories to build up a report. I have a client with literally 100s (perhaps 1000s) of such projects, and they need to catalog what tools/components/libraries/etc. they are using. Primarily so they can track EOL (end of life) and be less reactive to upgrades and such.
-
Sorry to post here, but I kept getting an error when posting a Question... I need a tool that can examine a Visual Studio project, and then spit out metadata - things like: - version of MS Build - Target .NET version - list of packages/dependencies/etc. I can build this, but if something already exists that would be preferable. Ideally it can scan projects in an Organization's Azure DevOps repositories to build up a report. I have a client with literally 100s (perhaps 1000s) of such projects, and they need to catalog what tools/components/libraries/etc. they are using. Primarily so they can track EOL (end of life) and be less reactive to upgrades and such.
Andreas Mertens wrote:
Looking for a tool...
One lives a few doors down from my house.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Andreas Mertens wrote:
Looking for a tool...
One lives a few doors down from my house.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak:) If I thought that would help...
-
Sorry to post here, but I kept getting an error when posting a Question... I need a tool that can examine a Visual Studio project, and then spit out metadata - things like: - version of MS Build - Target .NET version - list of packages/dependencies/etc. I can build this, but if something already exists that would be preferable. Ideally it can scan projects in an Organization's Azure DevOps repositories to build up a report. I have a client with literally 100s (perhaps 1000s) of such projects, and they need to catalog what tools/components/libraries/etc. they are using. Primarily so they can track EOL (end of life) and be less reactive to upgrades and such.
After chuckling at Dave's answer and also thinking 'I see a lot of tools' when I read your question, I did think there used to be something around - I'm still looking for it though I do see things like [Project Class (Microsoft.Build.Evaluation) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.evaluation.project?view=netframework-4.8) but not the cohesive example I thought was out there (could have been ages ago)
-
After chuckling at Dave's answer and also thinking 'I see a lot of tools' when I read your question, I did think there used to be something around - I'm still looking for it though I do see things like [Project Class (Microsoft.Build.Evaluation) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.evaluation.project?view=netframework-4.8) but not the cohesive example I thought was out there (could have been ages ago)
I was not aware that class even existed - thanks for pointing it out. I need to explore that namespace a bit more too...
-
:) If I thought that would help...
Oh, I'm sorry! I didn't read your entire post. I didn't know you were looking for THAT kind of tool! :)
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Sorry to post here, but I kept getting an error when posting a Question... I need a tool that can examine a Visual Studio project, and then spit out metadata - things like: - version of MS Build - Target .NET version - list of packages/dependencies/etc. I can build this, but if something already exists that would be preferable. Ideally it can scan projects in an Organization's Azure DevOps repositories to build up a report. I have a client with literally 100s (perhaps 1000s) of such projects, and they need to catalog what tools/components/libraries/etc. they are using. Primarily so they can track EOL (end of life) and be less reactive to upgrades and such.
If you write it yourself, you're going to have to deal with several variations of the Visual Studio project, even if you limit yourself to recent versions of Visual Studio. There's the "traditional" project format:
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
For that, the NuGet package references can either be stored in a
packages.configfile, or as<PackageReference>elements in the project file. They'll also be listed as<Reference>elements within the project file. And you'll have a reference for the complete dependency tree of NuGet packages which the referenced packages depend on. Then there's the "SDK-style" project:<Project Sdk="Microsoft.NET.Sdk">
That should always have NuGet package references stored in the project file. It will only have references for the packages which the project directly depends on; any dependencies of those packages will not be listed. And if they created any .NET Core RC1 projects with VS2015, you may also have to deal with
xproj+project.jsonprojects, which don't use XML at all. project.json and csproj comparison - .NET Core CLI | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
If you write it yourself, you're going to have to deal with several variations of the Visual Studio project, even if you limit yourself to recent versions of Visual Studio. There's the "traditional" project format:
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
For that, the NuGet package references can either be stored in a
packages.configfile, or as<PackageReference>elements in the project file. They'll also be listed as<Reference>elements within the project file. And you'll have a reference for the complete dependency tree of NuGet packages which the referenced packages depend on. Then there's the "SDK-style" project:<Project Sdk="Microsoft.NET.Sdk">
That should always have NuGet package references stored in the project file. It will only have references for the packages which the project directly depends on; any dependencies of those packages will not be listed. And if they created any .NET Core RC1 projects with VS2015, you may also have to deal with
xproj+project.jsonprojects, which don't use XML at all. project.json and csproj comparison - .NET Core CLI | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Exactly. If everything was built using (pretty much) the same tools, then great, otherwise...there's always going to be some hole and the assessment is always going to remain incomplete. What impact that has on the answer it'll find for you depends on the question being asked.
