| 29 Apr 2025 |
ortolanbunting3002 | Would it theoretically be possible to install the workloads using nix?
| 18:57:19 |
6pak | yeah | 18:58:07 |
6pak | just no one implemented that | 18:58:10 |
Emma [it/its] | In reply to @6pak:matrix.org while sdk_9_0 currently aliases to the binary one Oh huh, i should switch then, i thought both were source built | 20:09:28 |
Corngood | It's a bit more complicated than that. The runtime is always source built unless you use -bin, and the sdk will be source built if you use -source, or if you use the 1xx feature level ask, since it can be built from source | 20:53:53 |
Corngood | * It's a bit more complicated than that. The runtime is always source built unless you use -bin, and the sdk will be source built if you use -source, or if you use the 1xx feature level sdk, since it can be built from source | 20:54:09 |
6pak | (tldr the sdk is currently binary :)) | 20:54:30 |
6pak | * (tldr the sdk_9_0 is currently binary :)) | 20:54:41 |
Corngood | Yeah, but the sdk includes the runtime, so if you care about running on the source built runtime it might matter | 20:57:31 |
ortolanbunting3002 | In reply to @6pak:matrix.org . With this workaround I can install the workloads, but they are still ignored by dotnet restore
| 21:17:06 |
ortolanbunting3002 | In reply to @ortolanbunting3002:tchncs.de In reply to @6pak:matrix.org . With this workaround I can install the workloads, but they are still ignored by dotnet restore
Ah, how do I use them then?
| 21:20:03 |
| 1 May 2025 |
| Rosuavio changed their display name from Rosario Pulella to Rosuavio. | 20:08:19 |
| 3 May 2025 |
Whovian9369 | It seems that nuget2nix doesn't support spaces in the projectFile value, from what I can tell?
dotnet-sdk = dotnetCorePackages.sdk_9_0;
dotnet-runtime = dotnetCorePackages.runtime_9_0;
nugetDeps = ./deps.json;
projectFile = "mbundle extractor/mbundle extractor.csproj";
selfContainedBuild = false;
dotnetBuildFlags = [ "--framework net9.0" ];
dotnetInstallFlags = [ "--framework net9.0" ];
$ ./fetch-deps deps.json
fetching dependencies for rune-factory-4-special-mbundle-extractor-unstable-2021-12-30
Running phase: unpackPhase
unpacking source archive /nix/store/knnjxlszi45ylm5m4hj8lkjfjyrx09vj-source
source root is source
Running phase: patchPhase
Running phase: configureNuget
The template "NuGet Config" was created successfully.
Processing post-creation actions...
Running phase: updateAutotoolsGnuConfigScriptsPhase
Running phase: configurePhase
Executing dotnetConfigureHook
MSBUILD : error MSB1009: Project file does not exist.
Switch: mbundle
| 03:12:55 |
Whovian9369 | Similar issue if I do "'mbundle extractor/mbundle extractor.csproj'"
Switch: 'mbundle | 03:13:22 |
Whovian9369 | Used repo is https://github.com/darkxex/Rune-Factory-4-Special-Mbundle-Extractor | 03:14:45 |
6pak | ✨️ bash ✨️ | 03:16:14 |
| 5 May 2025 |
GGG | well, I don't know how reliable it is, but it seems like the only way to figure out whether an ELF is an apphost or not is grep 'You must install .NET to run this application.' | 14:11:12 |
GGG | I don't know if anyone else has a better method to do it | 14:11:21 |
GGG | * I don't know if anyone else has a better (or more reliable?) method to do it | 14:12:12 |
| 6 May 2025 |
Waldemar Tomme (they/them) | Just a 5min guess: Could the output of binwalk help here?
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 ELF, 64-bit LSB shared object, AMD x86-64, version 1 (SYSV)
14137 0x3739 Unix path: /usr/share/dotnet
I did not investigate what's stored at that offset or if it even is at the same offset but this seems like it might be a bit more reliable...
| 06:12:20 |
Waldemar Tomme (they/them) | (I tried it on an already patched version because I did not have anything else lying around, so it might also be a red herring) | 06:13:16 |
GGG | hm, I'll check | 13:44:27 |
GGG | is the hex the offset? | 13:44:34 |
Corngood | /// <summary>
/// hash value embedded in default apphost executable in a place where the path to the app binary should be stored.
/// </summary>
private const string AppBinaryPathPlaceholder = "c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2";
private static readonly byte[] AppBinaryPathPlaceholderSearchValue = Encoding.UTF8.GetBytes(AppBinaryPathPlaceholder);
this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison
| 13:45:06 |
Corngood | * /// <summary>
/// hash value embedded in default apphost executable in a place where the path to the app binary should be stored.
/// </summary>
private const string AppBinaryPathPlaceholder = "c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2";
private static readonly byte[] AppBinaryPathPlaceholderSearchValue = Encoding.UTF8.GetBytes(AppBinaryPathPlaceholder);
this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison
it's also in singlefilehost
| 13:45:23 |
Corngood | #define EMBED_HASH_HI_PART_UTF8 "c3ab8ff13720e8ad9047dd39466b3c89" // SHA-256 of "foobar" in UTF-8
#define EMBED_HASH_LO_PART_UTF8 "74e592c2fa383d4a3960714caef0c4f2"
#define EMBED_HASH_FULL_UTF8 (EMBED_HASH_HI_PART_UTF8 EMBED_HASH_LO_PART_UTF8) // NUL terminated
bool is_exe_enabled_for_execution(pal::string_t* app_dll)
{
constexpr int EMBED_SZ = sizeof(EMBED_HASH_FULL_UTF8) / sizeof(EMBED_HASH_FULL_UTF8[0]);
constexpr int EMBED_MAX = (EMBED_SZ > 1025 ? EMBED_SZ : 1025); // 1024 DLL name length, 1 NUL
// Contains the EMBED_HASH_FULL_UTF8 value at compile time or the managed DLL name replaced by "dotnet build".
// Must not be 'const' because std::string(&embed[0]) below would bind to a const string ctor plus length
// where length is determined at compile time (=64) instead of the actual length of the string at runtime.
static char embed[EMBED_MAX] = EMBED_HASH_FULL_UTF8; // series of NULs followed by embed hash string
static const char hi_part[] = EMBED_HASH_HI_PART_UTF8;
static const char lo_part[] = EMBED_HASH_LO_PART_UTF8;
| 13:46:56 |
GGG | isn't that replaced though | 13:48:11 |
Corngood | binwalk doesn't work for me for a trivial apphost build dotnet new console, because the only thing changed in the apphost is the dll name (above). it might work for singlefilehost, where the managed stuff is appended | 13:48:41 |
GGG | hm | 13:49:21 |
Corngood | it is, but the hi_part and low_part are kept so it can verify that the replacement has happened | 13:49:23 |