-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Environment variable to be more flexible in Blazor WebAssembly #20935
Comments
@jernejk thanks for contacting us. We'll evaluate this and update the issue appropriately. @SteveSandersonMS could we expose this on the start options? |
Yes, this is a great suggestion. In fact, adding an "environment" option to the Short-term workaroundIn the meantime, you can technically work around this by adding some code like the following to <script>
const originalFetch = fetch;
fetch = async (url, options) => {
const response = await originalFetch(url, options);
return url.endsWith('/blazor.boot.json')
? new Response(await response.blob(), { headers: { 'blazor-environment': 'MyCustomEnvironment' } })
: response;
};
</script> Clearly that's a bit hacky but it will do the job. Note for anyone else: the preferred way to control the environment is the HTTP headers on the |
Thanks, that worked great! :) I have written a blog post on how to make Blazor WebAssembly app work with appsettings.json and environments. :) https://jkdev.me/blazor-appsettings/?github Recent Google search still isn't finding any good solutions for appsettings.json in Blazor! The old blog post with embedded might be still useful for certain scenarios since the config is available right away (no need for download) and while not secure, it can obscure settings into a DLL. |
We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources. |
That's fine as long as we have a nicely documented way of doing this on GitHub Pages and Azure Blob Storage Websites. At the moment I found only this and it doesn't help. |
@javiercn I'll take a look at this. Can you let me know where this might get configured, and then where the |
@michaelrp I would start adding it here and then it needs to flow to where it is used here |
Is your feature request related to a problem? Please describe.
I'm currently trying to implement appsettings.*.json support.
I found this doc but not much else.
https://github.com/dotnet/AspNetCore.Docs/blob/1584f405e564a1d2ee974c128aac9bdfe5642949/aspnetcore/blazor/hosting-model-configuration.md
I was able to figure out how loading appsettings.json works and how appsettings.[env].json is decided and selected through reverse engineering but I couldn't figure out how would that work for GitHub pages or Azure Blob Storage Websites.
I found, that the header
Blazor-Environment
is how we control the environment and the header is determined by downloadinghttps://localhost:5001/_framework/blazor.boost.json
.The code that seems to decide the environment is in case 1.
There is a workaround for GitHub pages to add HTTP Headers but it won't be picked up by Blazor js script because it only works for
index.html
.Right now I'm writing a blog post on how to by-pass this problem by determining the environment via the current link and load correct app settings rather than use HTTP Header.
Describe the solution you'd like
Can we have a way to control what the environment is?
Can we override the environment in index.html, which can be modified at deployment?
Additional context
I'm using Blazor 3.2-Preview4 with Visual Studio 2019 16.6-Preview3.
Don't get me wrong, love the new feature and I just finished a blog post on how to make appsettings.json work similar as before in Preview3 only for Preview4 making it no longer the best solution. :) (although it still works, making appsettings embedded and update variables in build pipeline rather deployment pipeline)
The text was updated successfully, but these errors were encountered: