Skip to content

(#3835) Switch to using new csproj format #3836

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
Open
gep13 wants to merge 9 commits into
base: develop
Choose a base branch
from
Open

(#3835) Switch to using new csproj format #3836

gep13 wants to merge 9 commits into from

Conversation

@gep13
Copy link
Member

@gep13 gep13 commented Jan 21, 2026 •
edited
Loading

Description Of Changes

This PR changes the chocolatey/choco repository to use the new csproj format, rather than the old csproj format.
Also, the build process has been changed to use dotnet build rather than msbuild
In addition, NuGet packages have been updated, where possible.
Build configurations have been pruned, so only the required build configurations are left in place.

Motivation and Context

Moving forward, we are going to want to build for .NET, rather than .NET Framework, and making this switch will be a requirement. For now, doing this work here, while we are still targetting net48, means that other systems, such as Renovate, will be able to be used for dependency management.

Testing

Testing of this PR should be done in conjunction with the changes in the following PR's:

  • CLE
  • Agent
  • GUI
  • GUI Licensed Extension

All of the 5 Core Products have to continue to work together, including the ability to debug all the projects. We can't be in a position where some of them work, and others don't. They all have to work, or we can't move forward with this change.

NOTE: Due to the changes in this PR, it is NOT possible to use the Get-ChocoUpdatedDebugVersion.ps1 scripts to copy build artifacts to different locations. This process will have to be done manually, and it documented below.

  1. Check out the changes in this PR, the CLE PR, the Agent PR, the GUI PR, and the GUI Licensed Extension PR
  2. Run git clean -xfd in each product folder (to ensure that there are no stray files that could interfere with the testing
  3. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false in the CLI folder, to generate build artifacts that can be copied into other repositories
  4. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false --target=restore in the CLE repository - to restore all the NuGet packages that are required
  5. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false --target=restore in the Agent repository - to restore all the NuGet packages that are required
  6. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false --target=restore in the GUIrepository - to restore all the NuGet packages that are required
  7. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false --target=restore in the GUI Licensed Extension repository - to restore all the NuGet packages that are required
  8. From the CLI repository, copy the files from C:\code\choco\code_drop\temp\_PublishedLibs\chocolatey_merged into the following folders
  • CLE - C:\code\choco-licensed\src\packages\chocolatey.lib\2.6.0\lib\net48
  • Agent - C:\code\choco-licensed-services\src\packages\chocolatey.lib\2.6.0\lib\net48
  • GUI - C:\code\ChocolateyGUI\Source\packages\chocolatey.lib\2.1.0\lib\net48
  • GUI Licensed Extension - C:\code\chocolateygui-licensed\Source\packages\chocolatey.lib\2.1.0\lib\net48
  1. From the CLI repository, copy the files from C:\code\choco\code_drop\temp\_PublishedApps\choco_merged into the following folders
  • CLE - C:\code\choco-licensed\lib\Chocolatey
  1. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false in the CLE folder, to generate build artifacts that can be copied into other repositories
  2. From the CLE repository, copy the chocolatey.licensed.dll file from C:\code\choco-licensed\code_drop\temp\_PublishedLibs\chocolatey.licensed\net48 into the following folders:
  • Agent - C:\code\choco-licensed-services\src\packages\chocolatey-licensed.lib\7.0.0\lib\net48
  1. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false in the Agent folder
  2. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false in the GUI folder, to generate build artifacts that can be copied into other repositories
  3. From the GUI repository, copy the ChocolateyGui.Common.dll file from C:\code\ChocolateyGUI\code_drop\temp\_PublishedLibs\ChocolateyGui.Common\net48 into the following folders:
  • GUI Licensed Extension - C:\code\chocolateygui-licensed\Source\packages\chocolateygui.common\2.1.1\lib\net48
  1. From the GUI repository, copy the ChocolateyGui.Common.Windows.dll file from C:\code\ChocolateyGUI\code_drop\temp\_PublishedLibs\ChocolateyGui.Common.Windows\net48 into the following folders:
  • GUI Licensed Extension - C:\code\chocolateygui-licensed\Source\packages\chocolateygui.common.windows\2.1.1\lib\net48
  1. From the GUI repository, copy the contents of this folder C:\code\ChocolateyGUI\code_drop\temp\_PublishedApps\ChocolateyGui\net48 into the following folders:
  • GUI Licensed Extension - C:\code\chocolateygui-licensed\Lib\ChocolateyGui
  1. Run .\build.debug.bat --testexecutiontype=none --shouldrunanalyze=false in the GUI Licensed Extension folder
  2. Open Visual Studio, and attempt to debug each project, and make sure that it works as expected. NOTE: You may need to select a different build profile, but you should be able to debug each project without having to make any manual changes
  3. In Visual Studio, run both the Unit and Integration Tests for each project, and make sure that they all succeed.
  4. Take the artifacts of each PR build, and install them onto a test VM, and make sure that they install correctly
  5. Verify that all the artifacts within each package (both NuGet and Chocoaltey) and strong name signed, and Authenticode signed

Operating Systems Testing

Windows 11

Change Types Made

  • Bug fix (non-breaking change).
  • Feature / Enhancement (non-breaking change).
  • Breaking change (fix or feature that could cause existing functionality to change).
  • Documentation changes.
  • PowerShell code changes.

Change Checklist

  • Requires a change to the documentation.
  • Documentation has been updated.
  • Tests to cover my changes, have been added.
  • All new and existing tests passed?
  • PowerShell code changes: PowerShell v3 compatibility checked?

Related Issue

@gep13 gep13 requested a review from a team as a code owner January 21, 2026 14:54
@gep13 gep13 requested a review from pauby January 21, 2026 14:54
@gep13 gep13 mentioned this pull request Jan 21, 2026
Open
10 tasks
@gep13 gep13 requested a review from AdmiringWorm January 21, 2026 14:59
gep13 added 8 commits January 29, 2026 16:03
@gep13
(chocolatey#3835) Upgrade to new csproj format
a5a3478 
This was done in two stages.

1. Within Visual Studio, right click on the packages.config file, and
use the option to Migrate packages.config to PackageRefernce...
  This had the effect of deleting the no longer required
  packages.config file
2. Use the try-convert .NET Global Tool to convert the solution and the
contained project to .NET

This process wasn't perfect, and fix ups had to be made on the changes
that were made, and there was an element of trial and error to get to a
point where things were working correctly.

During testing, it was found that having an app.config within a
project, especially unit test projects, was causing a problem.  Where
necessary, every app.config file was removed, and instead two elements
were added into the csproj file to have the dotnet build create a
dynamic app.config file:

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

Also during testing, it was found that it was necessary to include the
following element:

<Configurations>Debug;Release;ReleaseOfficial</Configurations>

to ensure that each build configuration was respected.  Without this in
place, there was an error within Visual Studio when trying to change
from one build configuration to another.

A change was made in .NET where there is no longer a Target with a Name
of AfterBuild, instead, this has changed to be an AfterTargets
attribute, with the Name of build.  Without making this change, the
copying of the output assemblies to the required locations to make
debugging work wasn't being done.

Where possible, the number of direct PackageReferences has been pruned,
to leave only the specific references that are needed, relying on
transitive depdendencies to bring in the remaining packages.
@gep13
(chocolatey#3835) Necessary changes due to package updates
7b680c4 
This was mainly around changes in how NUnit and SimpleInjector works.
@gep13
(chocolatey#3835) Switch to build using dotnet build
7d5ff0a 
Rather than MSBuild.  While this is not a requirement, and we could
have continued to use MSBuild, it makes sense to make this jump now, so
that it is one less thing to do once we start thinking about building
for .NET, rather than .NET Framework.

Due to the version of InspectCode that is currently being used in
Chocolatey.Cake.Recipe, it is not possible to analyse the repository,
so we have had to turn this off.  This will be re-enabled, once we get
an updated version of Chocolatey.Cake.Recipe, with new tool versions.

Finally, the file paths were updated to reflect the new folder
structures.  Each project now include the target framework in the
output path. We only have one at the minute, but this might change in
the future.
@gep13
(chocolatey#3835) Add debugging profile
6aa05fd 
This allows the execution of debugging of CLI with different command
line parameters.  The usage of source list is just as an example.
@gep13
(chocolatey#3835) Bump nuspec dependency
dc7e56b 
The project is now using a new version of log4net, so we need to update
the nuspec file to reflect this.  At some point, we should switch to
building the nuget package using dotnet build, so that this manual step
will no longer be required.
@gep13
(chocolatey#3835) Change default config values
50e5775 
Due to the changes in how SimpleInjector works, in v5.5.0, we have to
change some of the default values for its configuration values.  This
essentially puts SimpleInjector back to how it used to work, before
v5.5.0. Don't really like doing this, but until we overhaul how all the
registrations are done, both here, and in CLE and Agent, this is the
best path forward.
@gep13
(chocolatey#3835) Change how registration is located
1c0ba6b 
We don't actually ever register a ChocolateyUnpackSelfCommand object in
the IoC container.  This only ever works due to the fact that
SimpleInjector was doing more work than it should.  Instead, we need to
locate the correct command from the collection of ICommands that are
registered, based on the CommandFor attribute that is applied to it.
This similar to how the GenericRunner itself does it.
@gep13
(chocolatey#3835) Remove reference to Chocolatey.PowerShell
da5f6ac 
The chocolatey.console project had a reference to the
Chocolatey.PowerShell when it wasn't needed.  Before, this wasn't
causing any problems, but with the uplift to the new csproj format, and
the fact that it brings in transitive dependencies into a project, the
fact that there is a StringResources in both chocolatey.lib and
Chocolatey.PowerShell (the file is linked from one project to the
other), it means that there are two references to the same thing, and
as a result, as usage of StringResources is broken.

Splitting the project reference seems like the correct course of
action.  The Chocolatey.PowerShell assembly is only used within the
PowerShell execution of Chocolatey CLI, so no direct project reference
should ever be needed.
@gep13 gep13 force-pushed the new-csproj-spelunking branch from 585ad5d to da5f6ac Compare January 29, 2026 16:04
@gep13
(build) Be explicit about location of snk file
39831db 
When doing an official build, the snk file that is used to strong name
sign the assemblies is in a different location to the default.  When
using the attribute in the SolutionVersion.cs file, this path was
updated on each build, however, when using the csproj file properties,
it is not as simply.  Let's check to see whether the environment
variable that stores this location has a value or not, and if it does,
use that value for signing.

This should mean that the paths in the SolutionVersion.cs file match
what is used in the csproj files, and once we move everything into a
Directory.props file, and remove the usage of the SolutionVersion.cs
file completely, everything should continue to work as expected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@pauby pauby Awaiting requested review from pauby pauby is a code owner automatically assigned from chocolatey/chocolatey-credits-reviewers

@AdmiringWorm AdmiringWorm Awaiting requested review from AdmiringWorm

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Switch to using the new csproj format

1 participant

@gep13