Xamarin Configuration Consistency Across Build Targets

Configuration Loading Behavior

In Xamarin, the way a configuration file is packaged and accessed at runtime is dictated by its BuildAction and the MSBuild linker settings that differ between Debug and Release configurations.

Confirmed facts

• Files marked as EmbeddedResource are compiled into the .NET assembly and can be read with Assembly.GetExecutingAssembly().GetManifestResourceStream in both Android and iOS builds.
• In Debug builds the linker is disabled by default, so all EmbeddedResource files are preserved.
• In Release builds the linker runs by default and will remove any embedded resource that the compiler cannot prove is referenced, which can lead to FileNotFoundException if the configuration file is not explicitly accessed in code.
• Using a relative file path (e.g., File.ReadAllText("config.json")) relies on the file being copied to the output directory. For Content files this copy happens only if the file is marked as Content and CopyToOutputDirectory is set, but these files are not automatically bundled into the final .apk/.ipa unless explicitly added to the platform‑specific asset or bundle settings.
• Conditional compilation symbols such as DEBUG affect #if blocks but do not remap resource paths; to have different configuration per build you need MSBuild <PropertyGroup Condition="$(ConfigurationName) == 'Debug'"> or a separate file per configuration.
• Xamarin.Forms XAML resource dictionaries must be set to BuildAction=Resource and referenced by full assembly-qualified names to be resolved at runtime.

Practical steps to guarantee consistency

1. Mark the configuration file as EmbeddedResource for every project (Android, iOS, shared).
2. Explicitly reference the file in code. For example:

   var assembly = typeof(App).Assembly;
   var stream = assembly.GetManifestResourceStream("MyApp.Config.config.json");
   var json = new StreamReader(stream).ReadToEnd();

   This guarantees the linker recognises the resource as used.
3. Disable the linker for a quick sanity test. In the project properties under Android Options or iOS Build, set Linker behavior to Don't link and rebuild Release. Verify the file is present.
4. Inspect the final package. Open the generated .apk or .ipa with a zip viewer. The embedded resource should appear under META-INF/ (Android) or the app bundle’s Resources/ directory (iOS).
5. Log available resources at runtime. Add a short snippet that enumerates Assembly.GetExecutingAssembly().GetManifestResourceNames() and logs whether the expected resource name is present. Run this on both Debug and Release deployments.
6. Compare the lists. If the Release build is missing the resource, adjust the linker settings or add a dummy reference in code to force inclusion.

Missing diagnostic detail

Could you confirm whether the configuration file is accessed via GetManifestResourceStream (code‑based) or through a relative file path (file‑system based)? The choice determines whether linker pruning or file‑copy settings are the primary risk factors.