Debug builds fail due to missing SearchCaptureStore references

[Caust2c]

Hello, I'm new to open-source contributions in general, so I wanted to check whether this is an intended issue before opening a PR or I'm just messing something up.

Problem

On a fresh checkout of the current master branch, Debug builds fail with:

C:\Users...\Seeker\SeekerApplication.cs(251,21): error CS0234:
The type or namespace name 'SearchCaptureStore' does not exist in the namespace 'Seeker.Debug'

C:\Users...\Seeker\Search\SearchFragment.cs(2345,29): error CS0234:
The type or namespace name 'SearchCaptureStore' does not exist in the namespace 'Seeker.Debug'

Command Used

dotnet publish .\Seeker\Seeker.csproj ^
-c Debug ^
-f net9.0-android ^
-p:AndroidSdkDirectory="%LOCALAPPDATA%\Android\Sdk" ^
-p:AndroidKeyStore=false

What I found

SearchCaptureStore is referenced as a type with members like Configure, Save, LoadRaw, and FileHelper in CaptureTestHelper.cs

With git log -S "SearchCaptureStore"

I found that the references were introduced in commit:

0d6cd01
debug helper to serialize and deserialize search responses debug vs debug mock

However, I couldn't find a corresponding implementation committed to the repository.

Was SearchCaptureStore intentionally omitted, or should these Debug-only references be disabled for clean checkouts?

I have a small local fix that allows Debug builds to succeed, but I wanted to check the intended behavior before opening a PR.

[jackBonadies]

Hi @Caust2c and thank you for your interest!

Looking into this - you are correct that the current debug configuration does not build. It has been a while since I did a clean clone of the repo (I have the files locally and so it builds without issue for me), but it seems like it has been broken for some time. It looks like this line in the .gitignore accidentally excluded the Common/Debug folder. This PR which I just merged should fix it.

SearchCaptureStore isnt strictly necessary - its just a way for me (in Debug) to record search results to disk and then play them back (in Debug Mock config) so I dont hammer the server as much and can get reproducible search queries in the case of troubleshooting issues.

Thanks and lmk if you run into any other issues building / running / debugging the project.

[Caust2c]

Thanks @jackBonadies ,

The SearchCaptureStore references are fixed now, and Debug builds successfully on a clean checkout.

However, I'm still seeing another issue with the Debug configuration:

• The generated Debug APK is only around 20 MB (much smaller than the signed Release APK).
• It installs successfully via adb, but opens and immediately closes on my phone.
• The Release build with signed keys behaves normally.

I also ran in the same issue after removing the SearchCaptureStore references, what worked for me was turning

<EmbedAssembliesIntoApk>False</EmbedAssembliesIntoApk>
to
<EmbedAssembliesIntoApk>True</EmbedAssembliesIntoApk>
(both two instances in Seeker.csproj)

The Debug configuration produced a larger APK and allowed it to run, although it still wasn't exactly the same size as the Release APK. I also noticed some occasional red border flashing (could be a layout bug) but it did work as the Release one would

Not sure if this is a related for the current Debug setup or a separate issue entirely. If it seems unrelated, please let me know and I can open a separate issue if that's the preferred approach.

[jackBonadies]

Thanks for pointing that out!

The red border flashing is an android debug feature (which can be disabled here) - its supposed to flash red any time there is I/O on the UI thread (though in practice, depending on the device, it flashes on any interprocess communication, toasts, etc. so there are many false positives).

As far as dotnet publish -c Debug not working, the Debug APK is not standalone (unlike Release) as you noticed the Debug config has EmbedAssembliesIntoApk set to False. The reason it is set to false is because it makes deployments much faster. This means that to deploy a Debug config to your device you have a few options -

1. Let Visual Studio do it - the Install Target will put managed assemblies into the internal directory on the device. This is the only way I ever deploy with Debug / Debug Mock builds which is why I actually never realized this was an issue.
2. Run the dotnet publish cli with -p:EmbedAssembliesIntoApk=true (this is what you noted, except as a command line option).
3. Run dotnet build .\Seeker\Seeker.csproj -c Debug -t:Install - I think this basically does the same thing as VS does.

All thats to say, its not a bug per se (since I think having EmbedAssembliesIntoApk set to false for debug is preferred, otherwise making small changes and iteratively debugging / testing takes forever) but it does point to the fact that this project needs better documentation in DEVELOPMENT.md.

[Caust2c]

Thanks for the explanation, really appreciate the patience!

That makes a lot more sense now. I was just installing the Debug APK directly via adb, so I was missing the managed assemblies that Visual Studio normally deploys separately.

Also, thanks for updating DEVELOPMENT.md, will probably help peeps like me.