.NET7 is currently in beta for Optimizely Configured Commerce. Talk to your implementation partner about reviewing your custom extensions as they begin testing .NET7.
Pull the most recent code from github. When merging, pay close attention to the changes in base for both the
.csproj files. The
.sln has moved to the root and now has references to projects for the Storefront Api, Admin Api, Integration, the Docker compose, and files at the root of the project.
The Extensions project now supports targeting .Net 7.0. There are new properties in the
.csproj that are conditionally included based on the target framework. These must be included in
.csproj to get the project to build. Any third-party references should be included or excluded based on the .NET versions they support. By default it targets
net48. That can be changed to
InsiteCommerce.Web causes a build failure if you set your Extensions project target to
net7.0. This is a known issue that will be resolved in a future release. For now, you can remove the project reference to
You most likely need to make a changes to your Extensions code before you are able to build it successfully. The .NET7 framework article contains additional details on some of the common scenarios you might run see. You must build your Extensions project before you can run the code locally.
Local development is now done via Docker. All necessary base code and services are containerized via a single command included in your project. Before you run this, there are a few things you should consider.
Docker’s default naming convention differs when running your application with the CLI versus running it with Visual Studio. To avoid challenges associated with overlapping container names, you should choose a name for your collection of containers before building them. When running docker with the CLI, you can specify the name for the project with the -p option. A similar result can be achieved by adding the
DockerComposeProjectName property in the
.dcproj file in the project root.
The database for your application is created within the Docker project by default. If you have an existing database that you would like to use instead, you can modify the database connection string with the
.env file in the project root.
The database and ElasticSearch containers mount their data to your OS’s file system in your project root. This allows the databases and ElasticSearch indexes to be persisted between Docker project builds. You can change the location of this mount by modifying the
docker-compose.yml file in the project root.
You can run your project in one of a few ways.
docker compose up -d from the root of your project. It starts up all necessary containers including mssql and elasticsearch.
Visual Studio 2022 can run and debug a Docker project. Select the InsiteCommerce Docker project from the Startup Projects drop-down list and begin a debug session. This builds your Extensions project and creates all necessary Docker containers.
There is a run configuration included with the release titled InsiteCommerce. It can be used to start up the containers in the docker compose file and attach a debugger.
If you are running a Spire site, you must build Spire separately. If you are using the default Docker compose, Spire uses
http\://localhost:30000 as its API URL. The Docker project uses NGINX to route all API requests from this endpoint to the appropriate services. Once your Spire build is complete, you can access your local site by using whichever port you have configured for your node server, such as
If you are running a Classic site, you can access your local website on
DatabaseUpdater fails to start – When initially running
docker compose up -dthe DatabaseUpdater container will fail. This is because when mssql starts for the first time it does not contain an "Insite.Commerce" database. As a work around restore a database to mssql after it is running, then rerun
docker compose up -d.
DatabaseUpdater does not run the sql scripts from Extensions – The DatabaseUpdater container does not include the Extensions.dll so it is not able to run any sql scripts from it. As a work around, you can point a net48 site at the same database and run any sql scripts.
FileSystem StorageProvider has issues – By default ConfiguredCommerce uses the FileSystem. With three running containers that do not share a file system, it does not work as expected. Optimizely plans on evaluating if the same directory can be mapped into the three running containers or if LocalStack must be included in the docker compose.
Error Page/Modal is blank – When an exception occurs loading a page, or making a request to an API, an elmah error details page is displayed. When running in the container setup with
ASPNETCORE_ENVIRONMENT=Developmentit takes ~10 seconds to load the error details to populate the page.
Exceptions not logged to ApplicationLog – When an exception occurs while running in the container setup with
ASPNETCORE_ENVIRONMENT=Developmentthose exceptions are not logged to the ApplicationLog table. The exception details are written out to the console of the container.
Updated 16 days ago