I have some tiered ABP.IO application template project deployment questions - but they may be ASP.NET Core deployment questions.
Background
I'm a bit confused as to whether I need to create appsettings.Production.json files to mirror the appsettings.json files in my class library projects (MyProduct.Application, MyProduct.Application.Contracts, etc.) AND my four ASP.NET projects (MyProduct.HttpApi.Host, MyProduct.IdentityServer, MyProduct.Web, and MyProduct.Web.Public) OR whether I just need to create them for ONLY the four ASP.NET projects and make sure that the settings that are in the class library projects are represented in the ones for the ASP.NET projects.
Questions
Should I create appsettings.Production.json files in my class
library/DLL projects?
If yes to 1, will the launchSettings.json file be the right place to
ensure that the libraries are built with the production
configuration?
If yes to 2, are there any considerations when deploying to
production? I know I need to use an environment variable on the
server.
If no to 1 or 2, how do I build my libraries to use the production
configuration?
Is it possible to replace the client secrets wherever they may
appear? It would seem like it would be necessary but there's no help
on this in the documentation. Are there any considerations toward
doing this? Is a simple search and replace of all the default
secrets sufficient or are there code changes necessary?
Is it possible to replace all references to localhost with the FQDN
of the respective site (Host/API, IdentityServer, Web, Web.Public)?
The application template would require this, correct? I am doing an
IIS deployment currently - not a Docker or Kubernetes deployment.
What else am I missing?
Thanks for taking the time to comment. If you have a resource to share with me, please do. I cannot find a deployment guide or checklist on the ABP Framework site, ABP Commercial site, Community Forum, or Discord channel.
UPDATE
I have been through these two resources and I am a lot more educated about configuration in ASP.NET Core but I still cannot find the answer to my question about configuring class libraries in production. 1 - https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0 2 - https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-6.0
FINAL UPDATE
Eventually I just had to figure things out but Omer's answers make a lot of sense in hindsight.
My solution was to add the appsettings.Production.json files to each of the deployable projects as suggested below. You can read Omer's answer for details. I pretty much did everything that Omer suggested but I had not thought about the one shot seeding of the Identity Server database tables. That was truly helpful. My final hurdle was figuring out a way to perform DB Migrations on my local DB instance and my remote servers with just a click.
Through various posts, I eventually figured out that I could use the Launch Profile editor buried under the Debug section of the DbMigrator project properties, to create myself two Launch Profiles. I have one for local development and one for production - although through this mechanism, I don't see why you couldn't create one for each part of your staging pipeline.
It should be noted that I deleted the default profile which was named using the project name/namespace.
Here is the Launch Profile editor screen for the Development profile:
And here is the Launch Profile editor screen for the Production profile:
Of primary importance is the ASPNETCORE_ENVIRONMENT=Development environment variable in development and the ASPNETCORE_ENVIRONMENT=Production environment variable in production.
Exiting the editor produces the Properties folder and the contained
launchSettings.json file.
You could create this folder and file yourself without going through the editor. Here is the text of that file:
{
"profiles": {
"EnvironmentConfiguration.Cli (Development)": {
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
},
"EnvironmentConfiguration.Cli (Production)": {
"commandName": "Project",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Production"
}
}
}
}
Now when I want to run a schema migration, I can simply select the DbMigrator project as the startup project...
...and I will have two launch profiles in my debug menu:
Does anyone know of a better way?
I am using ABP with Blazor Wasm and IdentityServer is not seperated. So I am publishing only .Host and .Blazor projects.
No, you only need them for published projects (.Host, .Web, .Blazor etc)
Should I create appsettings.Production.json files in my class
library/DLL projects?
Libraries are not standalone projects. They are used by other projects (By .Host project or they can be used by another library project) So, they will take these configuration settings from live application (.Host, .Web, .Blazor etc)
If no to 1 or 2, how do I build my libraries to use the production
configuration?
These keys are using by IdentityServer and I think they are seeded to Database on initial migration. If you want to change them, you need to change them from appsettings.json files and change value in database also. By the way, it is encrypted and you need to change value in DB with new encrypted value. (https://support.abp.io/QA/Questions/441/About-changing-client-secrets)
Is it possible to replace the client secrets wherever they may
appear? It would seem like it would be necessary but there's no help on this in the documentation. Are there any considerations toward doing this? Is a simple search and replace of all the default secrets sufficient or are there code changes necessary?
Change "localhost" values to your FQDN in all appsettings.json files. Also there should be some changes in database for IdentityServer. Because in the initial migration, it is written on DB.
[dbo].[IdentityServerClientCorsOrigins].[Origin]
[dbo].[IdentityServerClientPostLogoutRedirectUris].[PostLogoutRedirectUri] [dbo].[IdentityServerClientRedirectUris].[RedirectUri]
Is it possible to replace all references to localhost with the FQDN
of the respective site (Host/API, IdentityServer, Web, Web.Public)?
The application template would require this, correct? I am doing an
IIS deployment currently - not a Docker or Kubernetes deployment.
Do not forget to install SSL. If you are using Cloudflare disable SSL from Cloudflare (If you have also in server) Because it may conflict.
Another important thing is to remove Webdav if you are using IIS. Because Webdav occurs error for put request. (https://stackoverflow.com/a/59235862/2178028)
Also, I dont know why but for the first publish of Blazor projects, it gives 403 error for .dll files in ISS. Then I follow this link (https://www.eugenechiang.com/2021/12/12/failed-to-find-a-valid-digest-in-the-integrity-attribute-for-resource-in-blazor-app/) and problem is solved.
What else am I missing?
actually configuration of development mode different from production mode so to handle this you must use appsetting.production.json
answer for first question is no, because all projects use ui project settings by dependency injection
Related
Im looking to add a web.config (or app.config) so that i can have different settings (e.g. DEV build vs RELEASE build, for instance).
Can i simply add a .config file and expect to read from it?
I noticed that there is also an option to add a appsettings.json (App Settings File).
Which one of these should i be using for Blazor Client app (hosted via Asp.net)?
Thanks
Updates
Based on the following thread, i might just go with a settings
file on the Server side and feeding it to the Client via API.
Here is another reference for appsettings.json vs web.config
I was able to find a more concrete example int this article.
I believe you can use appsettings.Development.json and appsettings.json
Hope this helps...
I'm changing a value in the advanced settings of the CMS, specifically the ProviderTypeName of Blogs -> Providers -> OpenAccessDataProvider
However, when rebuilding the site the setting is reverted to its default.
I believe this is happening because the property is stored in a file, and my build and deployment is overwriting it with whatever is in my repository.
Where is this setting stored in the file structure; or if I'm way off base in my assumption, how do I get this setting to stick?
You right, most probably you overrode configuration changes during the deployment. Most of the time, I am excluding all configuration during website deployments and from VS project.
By default, Sitefinity 10 is using a hybrid mode that stores configuration files on both the file system App_Data/Sitefinity/Configurations and the database in table [sf_xml_config_items]. Documentation: https://docs.sitefinity.com/auto-storage-mode-of-configurations
Also, there is a way to move configurations to database only: https://docs.sitefinity.com/database-storage-of-configurations
Hi I am trying to set up a dotnet core library app that requires certain information from a appsettings.json to run. I understand how to have an application use the appsettings.json file via the builder etc. However I also want my library to use this file for its own configuration. Obviously the consuming app would have to know the settings to have in the appsettings.json file but for my purposes that is not a problem. Does anyone have an example of this working? What I have found so far are not that great and involve loading the appsettings.json every time we instantiate the configuration class in the library. There must be a better way than this.
That's exactly Options are created for!
You should not read settings file - DI will give you strongly-typed class/struct with parameters you need. Loaded from all configured sources (appsettings.json, environment variables etc), and updated automatically (if required/configured).
Check this documentation - sample is pretty short and copy-pasting it here isn't wise.
In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
EDIT
The command line that works fine for publishing is
MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=
In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.
Some answers to your questions.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can
this be done? If I leave the username and password empty, I am
prompted for it. Is there a way like manually modifying the .pubxml
files?
Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know.
If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in
PublishProfileName.pubxml.user that is local to each user? I could
at least save the username but obviously don't want that to be checked
in.
We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.
If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.
We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of
The Configuration itself is not part of PublishProfileName.pubxml but is stored in
PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.
The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way:
msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.
You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.
To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.
Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.
By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.
Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.
Currently I am using ms-deploy to build and deploy on several machines using team-city. In my current scenario, I need to build, package and deploy on Dev. After this I need to deploy this package on test and Live servers (which are on different domain. I understand how we do it but problem is Web transformation only occurs for test and live configs if we build a package. It means if I want to use the same package that is created for Dev cannot be used, as web transformation only occurred for Dev web config. Also know that we can change web config when un-packaging but that parameters are very limited. We have a lot of changes not just the connection string or db changes.
Another solution is to add another step to build packages for test and live as part of Dev deployment but then it means a lot of copying on remote servers, once for test and once for live which is a lot of time consuming due to different domains.
Can you please guide what is the best solution in this scenario. So I can use team-city to publish to Dev and test and live using same package and different web configs in one go.
To configure items at deployment time which are not automatically created for you. You can add a file named parameters.xml to your project and extend what you want to make available at deployment time.
Here's some documentation on the approach Using Deployment Parameters for Web.Config File Settings.