Skip to main content

[Obsolete] Azure deployment. Connectionstrings

Azure resource group

This template is used to create an azure deployment project. Based on a wizard, it generates file with list of console commands to perform the automatic deployment, with or without visual studio. After the project is created it can be configured and modified. Those types of projects are flexible and has a great possibility




Connectionstrings in azure

It's a common practice to use .config files to store connectionstrings, but it's not possible to identify what content should connectionstring have after deployment. There is a separate task to change .config file after deployment. To get rid of this task azure provides a new way of using connectionstrings from .config files: they are not used at all.
Azure provides a possibility to store connectionstrings as separate settings, which are accessible in azure portal in website settings. So connectionstrings block in .config file can be empty.

Connectionstrings in deployment

 
There is a possibility to configure those connectionstrings in deployment project. After creation of a web project deployment new section in .json file appears. This section shown in json outline window as connectionstrings and by default contains a connectionstring to database server mentioned in the wizard. That section can be edited according to application parameters. 

E.g. if.config file contains next connectionstrings:

<connectionStrings>
    <add name="DbModel" connectionString="..." providerName="..." />
    <add name="RedisCacheConnection" connectionString="..." />
</connectionStrings>
.json file can contains next lines:
"DbModel": {
              "value": "[concat('Data Source=tcp:', reference(concat('Microsoft.
Sql/servers/', variables('sqlserverName'))).fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('databaseName'), ';User Id=', parameters('administratorLogin'), '@', variables('sqlserverName'), ';Password=', parameters('administratorLoginPassword'), ';')]",
              "type": "SQLServer"
            },
"RedisCacheConnection": {
              "value": "[concat(parameters('RetRedisCacheName'),'.redis.cache.windows.net,abortConnect=false,ssl=true')]",
              "type": "SQLServer"
            }
It's obvious that connectionstrings names should fit each other and application can find the correct string while executed. Connectionstring in azure deployment is dynamically built, there are two ways to see the final connectionstrings: go to azure portal and check it there or download publish profile from azure website using visual studio. That file will contain publishing information, including generated connectionstrings.

Comments

Popular posts from this blog

[Obsolete] Azure package unpack and repack

Azure package There are a lot of possible scenarios of Azure deployment. Most of them are based on package that we can define and create with Visual Studio. If you need to change package use Visual studio to repack your project. To prepare specific web . config file, use different build configuration with transformation (web . config . release, web.config.debug etc.) Only when it's not possible to use Visual Studio to repack Azure package, then it's possible to repack it the way described below.

MS Dynamics CRM solutions storage model

It's not a secret that there are two types of solutions exists in CRM: managed and unmanaged. Each has it's own properties and capabilities. In general solutions can be differentiated by next points Managed solution Unmanaged solution Completed solution Cannot be exported Deleted with all its changes and components Under development Can be exported as managed Can’t undo changes done by import   Let's see what makes them behaves in a different way.