#959043 RFP: msbuild -- build platform for .NET and Visual Studio

#959043#5
Date:
2020-04-28 18:53:18 UTC
From:
To:
* Package name    : msbuild
  Version         : 1:16.5+xamarinxplat.2020.01.10.05.36
  Upstream Author : Jo Shields <joshield@microsoft.com>
* URL             : http://www.github.com/mono/msbuild
* License         : MIT
  Programming Lang: C#
  Description     : build platform for .NET and Visual Studio

 The Microsoft Build Engine is a platform for building applications.
 This engine, which is also known as MSBuild, provides an XML schema
 for a project file that controls how the build platform processes
 and builds software. Visual Studio uses MSBuild, but MSBuild does
 not depend on Visual Studio. By invoking msbuild.exe on your
 project or solution file, you can orchestrate and build products
 in environments where Visual Studio isn't installed.
----

I personally find this request to be important because Debian and its
derivatives only ship mono-xbuild, which is deprecated. It tells users
to use the MSBuild package instead, but so far there is no MSBuild
package except if the Mono repository is added to sources.list.

However, because I am planning to make a package for my Visual Basic
application to install flawlessly without requiring the addition of
Mono's repository, I find that adding the requirement to add their
repository just for one MSBuild package is so unnecessary.

So, I use it to build Visual Basic and C# solutions during the package
build step.

There is one package that is Mono's implementation of MSBuild called
mono-xbuild, but it's deprecated and based on Visual Studio 2015, so
that package doesn't fit my needs, because I don't want to use
deprecated packages to build my solutions and to make packages based
on them.

msbuild as a source has two binary packages:

* msbuild: This package contains the main msbuild build system
* msbuild-sdkresolver: This package contains the managed portion of the
  helper library which will auto-discover the .NET Core SDK on your system

#959043#14
Date:
2025-01-21 13:31:17 UTC
From:
To:
Greetings, Mr. Le Gonidec.

I'd urge you to take a look at these:

RFP: msbuild -- build platform for .NET and Visual Studio
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959043

mono-xbuild: Mono packages should provide msbuild instead of xbuild
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033828

As far as I'm aware, the Mono project used to have its own deb
repository, which included among other things msbuild and nuget
packages. Personally I'm not seeing any licensing obstacles that would
impede their inclusion into the official Debian repository.

Also, I may not be completely sure, but apparently Mono uses its own
patched version of MSBuild which is published here:
https://github.com/mono/msbuild
(Please note the tags as well.)

There is also a "Linux packaging" repo here, it includes the debian
folder which might be easier to adapt to current sid/testing
dependencies and packaging policies:
https://github.com/mono/linux-packaging-msbuild

Meanwhile, the upstream repository of MSBuild (as maintained by
Microsoft) apparently only has support for .NET Core included out of
the box.

What do you think of this?

Sincerely,
Ilyas Gasanov

#959043#19
Date:
2025-01-21 13:43:19 UTC
From:
To:
Thanks for your interest for Mono in Debian, that clearly goes far
beyond my own ;)

For a bit of context, Mono was facing removal from Debian after several
years being unmaintained. I took over its maintenance because I rely on
the Mono runtime binary and libraries for some other project of mine
(https://wiki.debian.org/Games/PlayIt).

On the other hand, I am not interested at all in Mono (or .NET) as a
development platform. So don’t expect me to work on adding support for
new packages that would only have some use in this context.

Actually my current plan is to remove several binary packages built from
the mono source package, reducing its scope until only the runtime
binaries and libraries are still provided in Debian.

So if some of you want to keep Mono/.NET as a development platform in
Debian repositories, the only way it has a chance to happen is if you
join the maintenance effort. By "joining the effort", I mean you would
have to introduce and maintain any new package yourselves (or find other
interested maintainers and start a team effort).

I hope this summary makes it a bit clearer what the current state of
Mono in Debian is, and what can be expected for as long as I am the only
one willing to work on it.

#959043#24
Date:
2025-01-21 14:04:25 UTC
From:
To:
Understood.

In this case, can I ask you to create a Request For Adoption (RFA) on
WNPP channel, so that other potential maintainers would be able to
take note of this?

вт, 21 янв. 2025 г. в 17:43, Antoine Le Gonidec <debian@dotslashplay.it>:

#959043#29
Date:
2025-01-21 14:15:55 UTC
From:
To:
Le Tue, 21 Jan 2025 17:53:48 +0400,
Ilyas Gasanov <torso.nafi@gmail.com> a écrit :

Mono is already listed on https://wiki.debian.org/LowThresholdAdoption

The main reason there is no RFA yet is that there are still many things
I want to fix in the current packaging (it accumulated many problems
over the years).

Since I took over its maintenance I’ve been working on fixing them, my
current priority order being:
1. Fix the problems reported on https://tracker.debian.org/pkg/mono
2. Switch to the new upstream maintained by the WINE team
3. Remove *unused* binary packages to reduce the maintenance scope
(anything with reverse dependencies or reverse build-dependencies is
going to stay)

Of course, even without having submitted this package explicitly for
adoption, I would be more than happy to see other people joining the
maintenance of the mono source package. If they have objectives
different than mine it’s not a problem, on the contrary: each
co-maintainer could then focus on the parts they really care about.

I think there is a wnpp report category more appropriate when asking
for co-maintainers… Maybe RFH?

#959043#34
Date:
2025-01-21 15:02:20 UTC
From:
To:
Yes, I believe an RFH would be more suitable in this scenario.

P.S. I personally can consider co-maintaining, however I cannot really
guarantee any particular level of availability for maintenance tasks at
this point.

вт, 21 янв. 2025 г., 18:14 Antoine Le Gonidec <debian@dotslashplay.it>: