We Keep Coding

Run a function just once in StartUp.cs After application Deployment

I am developing ASP.NET core 2.2 web application. I want to run a function just once after the application is deployed each time in Startup.cs file.
This function slows down the application as it does some heavy checks on the application startup. I only want to run this just once each time when the application is deployed.
This is the code
SynapseCore.Services.Plugins.SiteContentDiscovery iCont = new SiteContentDiscovery();
_logger.LogInformation("Startup - Complete : SiteContentDiscovery", new object[0]);
SynapseCore.Shared.GlobalData.pluginList = pluginsInfoList;
_logger.LogInformation("Startup - Complete : pluginList", new object[0]);
iCont.SetPluginInfo(pluginsInfoList);
_logger.LogInformation("Startup - Complete : SetPluginInfo", new object[0]);
//The following function 'CheckDatabaseIntegrity' is to be run once after deployment.
iCont.CheckDatabaseIntegrity();
_logger.LogInformation("Startup - Complete : CheckDatabaseIntegrity", new object[0]);
iCont.CheckPluginStatus();
_logger.LogInformation("Startup - Complete : CheckPluginStatus", new object[0]);
PluginSiteComposedData composedData = iCont.CompileSiteDataList();
I have looked into
Environment.GetEnvironmentVariables()
But doesn't seem to have that attribute i am looking for.
My question is, how do i detect through code if the application is running for the first time after deployment on IIS ?

You could simply store and check the assembly version. If it increased you can assume that you deployed a new version.
But you also have to increase it in your project properties each time you want to deploy a new version.

read from app.config instead of dll.config

I have simple console application. In application there is app.config and i have defined few settings which i fetch using ConfigurationManager class like below
var setting = ConfigurationManager.AppSettings[key]
This works ok when i am debugging on local env. Now when i deploy this code to develepment server then it reads setting from dll.config instead of app.config.
I tried to google but i am not able to find any clue.
Is it possible to change behaviour to read from app.config always? The reason i am asking is because i have added transformation for app.config. So for Dev server its called app.DevServer.config and it has some specific settings.

Yes, you can manually read your app.config file with code like this:
var configMap = new ExeConfigurationFileMap { ExeConfigFilename = "app.DevServer.config" };
var config = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None, true);
var setting = config.AppSettings.Settings[key];

Publishing a shared appsettings file with .net core

I have a .net core solution that contains a database project (class library) and a console application. The database project contains EF Migrations and to do Add-Migration, most methods use a hard-coded connection string in one place or the other.
To avoid hard-coding (and/or duplication) I have created a shared appsettings.json file in the solution root and I use it in my Main method and the class library
In the console application
static void Main(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(#"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var services = new ServiceCollection()
.AddDbContext<MyContext>(options => options.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]))
.BuildServiceProvider();
}
And in the class library to use migrations
public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<MyContext>
{
public MyContext CreateDbContext(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(#"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var optionsBuilder = new DbContextOptionsBuilder<MyContext>()
.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]);
return new MyContext(optionsBuilder.Options);
}
}
This is working well for development purposes when I use dotnet run but when I publish the console application, it doesn't include the appsettings file. Other than running a powershell script as part of dotnet publish, is there any other cleaner way of including this file when the project is published?

IDesignTimeDbContextFactory is exactly for the purpose its name describes. You shouldn't be running migrations against your production database in the first place, and if you do, you should be generating specific migrations for production into your app (instead of the class library) and using your app for the migrations. See the docs on using a separate project for migrations. That, then, negates the need to share your appsettings.json. Just leave the connection string hard-coded in your factory, since it's only for development anyways.
Now, you might have an issue I suppose in a team environment. However, even if you're using something like SQLite, you can use project-relative paths that won't be developer-specific, and with LocalDB, you can use a normal SQL Server connection string to the MSSQLLocalDB instance, which will be same for every developer using Visual Studio. Regardless, even if you do need to specify the connection specifically by developer, at that point it would make more sense to use user secrets, anyways, since you wouldn't want that info be committed to source control. Otherwise, each developer would end up clobbering the other's copy of appsettings.json, and you'd have a mess on your hands.
Long and short, just hard-code the connection string in your factory, or if you can't or won't, use user secrets for the connection string. In either case, you do not need to share appsettings.json.

The way I've done this before is to specify the startup project when you run dotnet ef (with the -s switch - the options are at https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet#common-options)
It gets messy quickly, and it's probably easiest to write some wrapper scripts for the project that deal with this kind of thing.

Can a non-SF project make use of the applicationmanifest configuration values?

I've got a Service Fabric Application set up in the following way:
Solution
--SF Project
--ApplicationManifest.xml
--Stateless Project (uses app manifest values)
--Stateless Project (uses app manifest values)
--Class Library (used as a repository by the above two projects)
How can I enable the class library to make use of the ApplicationManifest.xml configuration file from the SF Project?
To allow the projects to be able to use the AppManifest for build/deployment, they simply need to be created like so:
How does a project that does not get added as a Service Fabric project make use of the applicationmanifest?
The Service Fabric projects are able to use the appmanifest by including parameters in settings.xml and servicemanifest (but non-SF projects cannot):

Option #1
If you need to access the parameters defined in your service's setting.xml, the next should work -
In your non-SF project, install
Microsoft.Extensions.Configuration and ServiceFabric.Extensions.Configuration NuGet packages
Wherever you decide to access the parameters, use the next code snippet -
var builder = new ConfigurationBuilder().AddFabricConfiguration("Config");
var configuration = builder.Build();
var section = configuration.GetSection("MyConfigSection");
var parameterValue = section["MyParameter"];
One note though - you will get access to only one SF service at a time. That's because AddFabricConfiguration() works by calling FabricRuntime.GetActivationContext(), which ties settings being loaded with the SF service you're calling a non-SF code from.
Option #2
Next option will work from any place where you could establish connection with the SF. Using code below, you could read any parameter passed into the app manifest -
var fClient = new FabricClient();
var namespaceManager = new XmlNamespaceManager(new NameTable());
namespaceManager.AddNamespace("ns", "http://schemas.microsoft.com/2011/01/fabric");
var manifest = XDocument.Parse(fClient.ApplicationManager.GetApplicationManifestAsync("YOUR_APP_TYPE_NAME", "YOUR_APP_TYPE_VERSION").Result);
var parameterValue = manifest.XPathSelectElement("/ns:ApplicationManifest/ns:Parameters/ns:Parameter[#Name='PARAMETER_NAME']", namespaceManager).Attribute("DefaultValue").Value;

Modifying scriptmaps/handlermappings programmatically

I have some code to create a Virtual Directory programmatically.
I need to edit handler mappings of framework 2.0 to use .net 4.0 (basically run .net 2.0 code under .net 4.0 CLR).
The code below works fine under win 2003 server, but on Windows 2008 server webservicefactoryHandler2.0 is renamed as webservicefactoryHandler4.032_1245.
I don't know how to access/edit this name or infact retain the name and just change its value to \Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll from \Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll.
Dim scriptMapVals As PropertyValueCollection = VDir.Properties("ScriptMaps")
Dim objScriptMaps As ArrayList = New ArrayList()
Dim frameworkVersion As String = "4.0.30319"
Dim versionRegex As Text.RegularExpressions.Regex = New Text.RegularExpressions.Regex("(?<=\\v)\d{1}\.\d{1}\.\d{1,5}(?=\\)")
''Assuming the version will always be something like n.n.nnnnn
Dim scriptMapVal As String
For Each scriptMapVal In scriptMapVals
If scriptMapVal.Contains("Framework") AndAlso scriptMapVal.Contains("asmx") Then
objScriptMaps.Add(Text.RegularExpressions.Regex.Replace(scriptMapVal, versionRegex.ToString, frameworkVersion))
Else
objScriptMaps.Add(scriptMapVal)
End If
Next
VDir.Properties("ScriptMaps").Value = objScriptMaps.ToArray()
VDir.CommitChanges()
Update:
#kev : So basically you are saying to use different code for different version of IIS right? Well while using import "Microsoft.Web.Administration.dll" , do i need to pack it up in my build ? or this is part of all IIS7.0 installables? as Some poeple could have IIS7.0 on Windows XP.
Thanks
gauls

First of all, don't use the IIS6 compatibility API to manipulate IIS7 handler mappings. Use the Microsoft.Web.Administration managed API instead.
However, you're going about this in completely the wrong way. You shouldn't be touching the handler mappings but instead change the managed runtime version for the application pool in in which the application resides.
Add a reference to:
C:\Windows\System32\inetsrv\Microsoft.Web.Administration.dll
Then in your code:
using Microsoft.Web.Administration;
...
using (ServerManager serverManager = new ServerManager())
{
ApplicationPool appPool =
serverManager.ApplicationPools.Where(a => a.Name.Equals(appPoolName))
.Single();
appPool.ManagedRuntimeVersion = "v2.0";
serverManager.CommitChanges();
}
I would also recommend NOT using the ADSI compatibility API's at all to manipulate IIS7's configuration. Learn to love and embrace <applicationHost> and forget about thinking in terms of metabase objects in IIS7:
http://www.iis.net/ConfigReference/system.applicationHost
Update:
Further to your question about having code that works with both IIS6 and IIS7 I would thoroughly recommend NOT using the IIS6 compatibility layer for the convenience of having to maintain just one codebase.
The reason for this is that features of IIS7 objects such as HandlerMappings (the equivalent of Script Mappings) are handled differently. The compatibility shim creates what's known as ABO Custom Map objects which lose some of the benefits of proper HandlerMappings. Whilst they work they will create an administrative nightmare in the longer term. Trust me, I've been there.
If you need to detect which version of IIS your running then here is a handy function to do that:
public static int GetIIsMajorVersion()
{
string regKey = #"SOFTWARE\Microsoft\InetStp";
using(RegistryKey key = Registry.LocalMachine.OpenSubKey(regKey, true))
{
return Convert.ToInt32(key.GetValue("MajorVersion"));
}
}
If the return value is 6 then it's IIS6, if it's 7 then you're on IIS 7.x.