search

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

The name 'Secrets' does not exist in the current context #194

Closed v3gard closed 3 years ago

v3gard commented 3 years ago

Description

When you compile the sample application, you get the error message

The name 'Secrets' does not exist in the current context

This is solved by creating a placeholder file called Secrets.cs in the Helpers directory in Visual Studio, and adding the missing variables. The application then compiles, and the Secrets.cs file is replaced with autogenerated content.

Reproduction Steps

Steps to reproduce the behavior:

  1. Create a new project and include Mobile.BuildTools nuget package, or git clone the sample application at https://github.com/dansiegel/AppCenter.DemoApp
  2. Use the sample application, or create a class that depends on any given secret from secrets.cs.
  3. Try to build
  4. See error

Expected Behavior

It is not mentioned in the documentation that you need to create a blank Secrets.cs file the first time you compile an application using this library. As a first-time-user, you get the impression that this would work out of the box.

As a minimum, I would expect the sample application to contain a file with the required variables, where the secret values were set to dummy values, e.g. "replaceMe".

The documentation should also mention that you need to create the file the first time, and from that point, any future builds replaces said file with autogenerated content.

Depending on how you have configured your project, you could also get the compilation warning "'[...] Secrets.cs' specified multiple times". The documentation should mention the preferred approach for eliminating this issue. For me, I simply selected the Secrets.cs file I manually created in the Solution Explorer and excluded the file.

Actual Behavior

Compilation error.

Environment

Reproduction App

See sample application at https://github.com/dansiegel/AppCenter.DemoApp

gaurakshay commented 3 years ago

@v3gard In my experience, I built the app with the secrets in the json file before I referenced them. So basically the order of operations that works for me is:

  1. Add the secrets
  2. Build the app so that Secrets.cs file is created
  3. Reference the secrets where ever you need.
dansiegel commented 3 years ago

@v3gard a few things...

  1. The entire point of using the secrets.json is for the file to NOT exist in source control and thus prevent leaking potentially sensitive settings such as a Client Id or Client Secret.
  2. You're referencing an old Demo app which clearly tells you right in the ReadMe exactly what to copy and paste into a secrets.json to build locally and how to set it up in CI so that it will generate it for you...
  3. Again the entire point of this strategy IS to BREAK YOUR BUILD when you're missing configuration values. Yes you could have some place holder like "replace me" and the project will build however that will only lead to runtime crashes or things just not working. The point of Break the Build is to alert you earlier in the pipeline that you're missing configuration values.

Lastly I really can't find anything of value in this issue as I've spent A LOT of time on a full docs site which you clearly don't seem to be paying attention to as you're referencing v1.4 as we're working on releasing 2.0

v3gard commented 3 years ago

My intention with creating this issue was to provide feedback on the library's ease of use as seen from the perspective of a developer new to the library. The issue itself is trivial once you got it working once, and understand the workflow - but it was not that obvious when you tried your first compile.

Yes, I understand that 2.0 is underway, but most people use 1.4.0 still, and the DemoApp still uses 1.4.0. If it is the first time you use the library, that is not something you are aware of right away.

I gave the demo app another shot based on @gaurakshay's comment, and if you do it in his suggested order, the application compiles as expected. I probably messed up the order when I experimented with this earlier today and got confused with the docs at https://mobilebuildtools.com/ referencing the 2.0 release.

My two cents, which would make an otherwise excellent library even better. Put more emphasis on how to handle the secrets.json in the docs. If the intention is that the file should not be added at all, make it as clear as @dansiegel mentions above, and keep it short. If you are used to projects that use app.config, you usually commit the file to git with placeholder values for secret variables, and then override them in Azure.

dansiegel commented 3 years ago

If you are used to projects that use app.config, you usually commit the file to git with placeholder values for secret variables, and then override them in Azure.

Agreed that would be the way you would generally see with an app.config with 2.0 supports. As for it being confusing which documentation to refer to that part I can understand. This library is rather large, and to be pretty blunt I had to write the docs site just so I would remember all of the things that the Build Tools will do. So I do expect a certain amount of confusion when you first get started.

Not to say that it couldn't be better... If there are edits that you feel would be constructive I do accept PR's