dansiegel / Mobile.BuildTools

The Mobile.BuildTools makes it easier to develop code bases in a clean, consistent, secure, and configurable way. Determine at Build which environment your app needs to run on, and what Client Secrets it should have. Plus many more amazing features!
http://mobilebuildtools.com
MIT License
228 stars 29 forks source link

Add support for WPF desktop apps built on azure devops pipeline #129

Closed AdamDiament closed 4 years ago

AdamDiament commented 4 years ago

SUMMARY

I use the mobile build tools in a visual studio solution that contains iOS / Android xamarin.forms apps and a companion WPF desktop app. The mobile build tools secrets.json and helper class are generated inside a shared .net standard class library referenced by both the xamarin apps and the WPF app, via usage of [internalsVisibleTo] attributes in the WPF / xamarin projects.

For CI/CD I use App Center to build the xamarin apps. Mobile build tools picks up the env variables I set in the app center build config using the "secret_" prefix perfectly. For the WPF app I cannot build directly on app center, it doesn't have the feature to build WPF apps automatically. Although I can add a desktop "app" to app center and upload pre-built assets, I really want to automate the build step too.

As a workaround I am trying to build the WPF app on an azure dev ops pipeline using the standard desktop app pipeline template. I am running into the blocker that the secrets.cs class is not created during the "visual studio build" step, thus the build fails. The step uses MSBuild so I was hoping it would work but I think it needs some more configuration somewhere. (https://gyazo.com/efd7599824db205abc658e36ce4043dc)

I've tried adding my environment variables as pipeline variables with the secret_prefixes, but it doesn't change things.

Is there a step I am missing( e.g passing some custom MSBuild arguments to the build step?) or is dev ops "visual studio build" for WPF unsupported at the moment? And if so could you suggest a workaround or will I need to keep the secrets elsewhere for my WPF project as things stand?

Thanks again for the sterling work.


### PLATFORMS

<!-- which platform do you want? -->

- [ ] Android
- [ ] iOS
- [ ] UWP
- [x] New! WPF
dansiegel commented 4 years ago

@AdamDiament this is due to the fact that the Azure DevOps team doesn't know how their own systems work. On the Windows agents only the agents perform a ToUpper() on all variable names, making it impossible for the v1 buildtools to work. If you use the 2.0 preview it should solve your issue. It also eliminates the need to prefix with Secret_ since you define the variables in a centralized configuration for each project.

I'm going to close this issue as it should already be resolved. If I've missed something here and you're still blocked let me know and we can re-evaluate the issue.

AdamDiament commented 4 years ago

Thanks for the quick answer @dansiegel . I've got v2 installed now. I think azure dev ops is in a better state as I am seeing the mobile buildtools stuff in the logs now. However I get the messages

BuildHostSecrets:
  Output Path: [MY_PATH]\Settings\secrets.json
      No Build Host Secrets Found...
Secrets:
  No Secrets Json File was found.

in the logs just before the build failure which makes me think I'm setting up my variables wrongly as pipeline variables. I've tried with and without secret_ prefixes. Am I missing a step or putting the variables in the wrong place (I'm just adding them as regular pipeline variable)?

I tried looking at the docs at https://mobilebuildtools.com/continuous-integration/setup/ but couldn't work it out from there

dansiegel commented 4 years ago

you want to look here... https://mobilebuildtools.com/config/secrets/configuration/

The truth is you shouldn't need a prefix at all... one of the issues that I had actually discovered was that the Windows agents actually treat anything that starts with Secret_ as a protected variable meaning the Mobile.BuildTools can't find them unless you set the variable as an environment variable on the Task itself.

You can see more here... in the integration tests where we actually use a custom prefix just because.

https://github.com/dansiegel/Mobile.BuildTools/blob/e3d89ed7506875c3e90dccc489cf7d6d4ba625a8/build/jobs/integration-tests.yml#L22-L36

https://github.com/dansiegel/Mobile.BuildTools/blob/e3d89ed7506875c3e90dccc489cf7d6d4ba625a8/E2E/buildtools.json#L9-L47

AdamDiament commented 4 years ago

@dansiegel thanks for the help. I'm still having trouble unfortunately.

Interestingly the identical configuration seems to work on app center building my xamarin apps, but not on azure dev ops.

In app center, I get the following logs:

_LocateBuildToolsConfig:
  Auto-Generating BuildTools configuration at '/Users/runner/runners/2.166.4/work/1/s/SourceCode/ClientApps/Common'
BuildHostSecrets:
  Output Path: /Users/runner/runners/2.166.4/work/1/s/SourceCode/ClientApps/Common/VisualService.Settings/secrets.json
  Generating secrets.json
  {
    "BaseUrl": "*****",
..other secrets
  }

But in azure dev ops I get

BuildHostSecrets:
  Output Path: d:\a\1\s\SourceCode\ClientApps\Common\VisualService.Settings\secrets.json
      No Build Host Secrets Found...
Secrets:
  No Secrets Json File was found.

Azure dev ops doesn't seem to run the command _LocateBuildToolsConfig:, although it does run _EnsureScssRuntimeIsAvailable: just before it as per app center.

It's also an interesting message I get on app center **"Auto-Generating BuildTools configuration at ..."*** - does this mean it can't find my buildtools.json file in app center, but is handling it by autogenerating one for me? Or is this just the standard message and it has found my buildtools.json successfully?

This is my solution structure:

Root
       .sln
       buildtools.json
       SourceCodeFolder
             CommonFolder
                   buildtools.json (I also tried putting it here to try to match the app center logs of where it auto generated it, seems to make no difference)
                   SettingsProjectFolder
                       Settings.csproj - mobile build tools nuget v2 pre is installed here
             ClientAppsFolder
                    WPFapp.csproj - working fine locally, not working with mobilebuildtools on azuredevops
                    AndroidXamarinApp.csproj - working fine locally and on app center

This is my buildtools.json file

{
  "$schema": "https://mobilebuildtools.com/schemas/v2/buildtools.schema.json",
  "projectSecrets": {
    "VisualService.Settings": {
      "disable": false,
      "delimiter": ";",
      "prefix": "BuildTools_",
      "className": "Secrets",
      "namespace": "Helpers",
      "properties": [
        {
          "name": "BaseUrl",
          "type": "String",
          "isArray": false
        },
        {
          "name": "DebugLoginUserName",
          "type": "String",
          "isArray": false
        },
        {
          "name": "DebugLoginPassword",
          "type": "String",
          "isArray": false
        },
        {
          "name": "Native_Video_App_Id",
          "type": "String",
          "isArray": false
        },
        {
          "name": "Native_Video_App_Service_Name",
          "type": "String",
          "isArray": false
        },
        {
          "name": "Measurements_Service_Bus_Queue_Name",
          "type": "String",
          "isArray": false
        },
        {
          "name": "Measurements_Service_Bus_Queue_Connection_String",
          "type": "String",
          "isArray": false
        }
      ]
    }
  },
  "debug": false
}
AdamDiament commented 4 years ago

@dansiegel did you have a change to look at my last comment? Any thoughts / advice really appreciated.

dansiegel commented 4 years ago

Without seeing the YAML of what your build tasks look like or having a working reproduction here there's not a whole lot I can really do to help you out. Also keep in mind issues are a good place to report bugs and ask for features, but it doesn't rise to the level of support. If your company requires support I am available on a paid basis for support.

AdamDiament commented 4 years ago

@dansiegel Fair enough, will keep that in mind. Thanks a lot for the help you already gave.