Develop Reference

Properly configuring a dotnet (ASP.NET Core 2.1) environment on CentOS / Linux

I'm stuck, I'm really hoping someone can help or at least point me in the right direction. My end goal is to get my ASP.NET Core 2.1 app running on a CentOS Linux box. Since I'm using a mongo db in my actual app and wanted to eliminate any possible issues with that, I published a plain-jane asp.net core 2.1 mvc app, no authentication, and deployed it to a virtual host on my centos 7 box (apache upgraded via CoreIT to 2.4.37 since centos distros still deploy the older 2.4.6 version).
For the scope of this question I think I just need to make sure my reverse proxy is working properly and need help in pinning down that. I've followed instructions from here and the Microsoft setup doc from here. These 2 links are what I've been working with mainly.
When my app service is running, I can do a curl localhost:5000 and see the correct html of my homepage being returned. When I try from command line again with test.mydomain.com or test.mydomain.com:5000 it just times out. If I go to my app's conf (test.mydomain.com.conf in /etc/httpd/sites-available) and remove the ProxyPass, ProxyPassReverse and ProxyPreserveHost lines then I can hit test.mydomain.com from the outside with a browser and get my index.html file up and displaying properly (this is just one index.html file and not a part of the dotnet app though). It's only when I add the below back into my conf file it just hangs up when I try and hit the URL. I'm not sure what to look for in journalctl or maybe I should tail a specific log file to find out what it's waiting on and why it's taking so long.
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
Somehow is seems like my reverse proxy isn't set up right to be accessed from outside the box.
The rest of my app's config below.
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}</VirtualHost>
<VirtualHost *:80>
ServerName test.mydomain.com
DocumentRoot /var/www/test.mydomain.com/public_html
ErrorLog logs/dashboard.crtv1.com.errorlog
CustomLog logs/dashboard.crtv1.com.access_log combined
</VirtualHost>

I think I addressed the issue although I'm not sure what issues I was actually having at the time of posting. I ended up through process of elimination and curl to find another service was running and using port 5000 in another virtual host - we're doing development and need a test, staging and production set of virtual hosts. Also I found I had some code in my app (UseUrls) that was specifically stating to use port 5000 so multiple copies of it within the same environment had resource conflicts. I'll circle back and update which environments will use which ports and hopefully have a nice set up.

Windows Azure In-Role Caching Exception issue

I am getting this exception :-
ErrorCode:SubStatus:There is a temporary failure. Please retry later. (One or more specified cache servers are
unavailable, which could be caused by busy network or servers. For
on-premises cache clusters, also verify the following conditions.
Ensure that security permission has been granted for this client
account, and check that the AppFabric Caching Service is allowed
through the firewall on all cache hosts. Also the MaxBufferSize on the
server must be greater than or equal to the serialized object size
sent from the client.). Additional Information : The client was trying
to communicate with the server: net.tcp://RoleName:24233.
I have followed this :- Documentation and there are lots of questions and article there but they are little bit old.
Client creation :-
var cacheFactory = new DataCacheFactory();
_cacheClient = (string.IsNullOrWhiteSpace(cacheName))
? cacheFactory.GetDefaultCache() : cacheFactory.GetCache(cacheName);
WebConfig :-
<dataCacheClients>
<dataCacheClient name="default" >
<autoDiscover isEnabled="true" identifier="RoleName" />
</dataCacheClient>
Retry Policy :- It is inbuild now DataCacheFactory with interval of 1 minute and 60 recount.
I have latest nuget packages like Windows.azure.caching with version 2.5. So does anybody has solved this problem recently. i am quite a stuck here. any help is appreciated.

After hit and trial we have found that you should have the latest versions of both Windows Azure Tools and Windows Azure Cache libraries. What you can do is just install the latest Windows.Azure.Cache and then go to you publish azure settings project. Right click go to Properties => Application tab then upgrade the Windows Azure tools to latest version. And now everything will work like a charm :)
Hope it will save someone else day :)

VS2013 publish Web deployment task failed The file is in use

I am using VS2013 Premium to publish a site to Windows Server 2012.
All files publish ok except these:
SqlServerTypes\x64\msvcr100.dll
SqlServerTypes\x64\SqlServerSpatial110.dll
SqlServerTypes\x86\msvcr100.dll
SqlServerTypes\x86\SqlServerSpatial110.dll
I get this kind of errors for each of the above files I tried to publish:
Web deployment task failed. (The file 'msvcr100.dll' is in use. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
Interrestingly, these files were published the first time (when they were not on the server), then they are no longer overwritten. Tried with 2 different web servers.
I have followed the guide here:
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
...But it only managed to put the site offline (VS is placing the app_offline.htm) but publish still fails with the same error.
All other files publish perfectly.
Any ideas?

You can take you app offline during publishing which hopefully should free up the lock on the file and allow you to update it.
I blogged about this a while back. The support outlined was shipped inside of the Azure SDK and Visual Studio Update. I don't remember the exact releases but I can find out if needed. Any update dating around/after that blog post should be fine.
Prerequisites:
VS 2012 + VS update / VS 2013 + VS Update / VS2015
MSDeploy v3
Note: if you are publishing from a CI server the CI server will need the updates above as well
Edit the publish profile
In VS when create a Web Publish profile the settings from the dialog are stored in Properties\PublishProfiles\ as files that end with .pubxml. Note: there is also a .pubxml.user file, that file should not be modified
To take your app offline in the .pubxml file add the following property.
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
Notes
ASP.NET Required
The way that this has been implemented on the MSDeploy side is that an app_offline.htm file is dropped in the root of the website/app. From there the asp.net runtime will detect that and take your app offline. Because of this if your website/app doesn't have asp.net enabled this function will not work.
Cases where it may not work
The implementation of this makes it such that the app may not strictly be offline before publish starts. First the app_offline.htm file is dropped, then MSDeploy will start publishing the files. It doesn't wait for ASP.NET to detect the file and actually take it offline. Because of this you may run into cases where you still run into the file lock. By default VS enables retrys so usually the app will go offline during one of the retrys and all is good. In some cases it may take longer for ASP.NET to respond. That is a bit more tricky.
In the case that you add <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline> and your app is not getting taken offline soon enough then I suggest that you take the app offline before the publish begins. There are several ways to do this remotely, but that depends on your setup. If you only have MSDeploy access you can try the following sequence:
Use msdeploy.exe to take your site offline by dropping app_offline.htm
Use msdeploy.exe to publish your app (_make sure the sync doesn't delete the app_offline.htm file_)
Wait some amount of time
Publish the site
Use msdeploy.exe to bring the app online by deleting app_offline.htm
I have blogged how you can do this at http://sedodream.com/2012/01/08/howtotakeyourwebappofflineduringpublishing.aspx. The only thing that is missing from that blog post is the delay to wait for the site to actually be taken offline. You can also create a script that just calls msdeploy.exe directly instead of integrating it into the project build/publish process.

I have found the reason why the solution at
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
did not work for the original poster, and I have a workaround.
The issue with the EnableMSDeployAppOffline approach is that it only recycles the app domain hosting the application. It does not recycle the app pool worker process (w3wp.exe) which the app domain lives in.
Tearing down and recreating the app domain will not affect the Sql Server Spatial dlls in question. Those dlls are unmanaged code which are manually loaded via interop LoadLibray calls. Therefore the dlls live outside the purview of the app domain.
In order to release the files locks, which the app pool process puts on them, you need to either recycle the app pool, or unload the dlls from memory manually.
The Microsoft.SqlServer.Types nuget package ships a class which is used to load the Spatial dlls called SqlServerTypes.Utilities. You can modify the LoadNativeAssemblies method to unload the unmanaged dlls when the app domain is unloaded. With this modification when msdeploy copys the app_offline.htm the app domain will unload and then unload the managed dlls as well.
[DllImport("kernel32.dll", SetLastError = true)]
internal extern static bool FreeLibrary(IntPtr hModule);
private static IntPtr _msvcrPtr = IntPtr.Zero;
private static IntPtr _spatialPtr = IntPtr.Zero;
public static void LoadNativeAssemblies(string rootApplicationPath)
{
if (_msvcrPtr != IntPtr.Zero || _spatialPtr != IntPtr.Zero)
throw new Exception("LoadNativeAssemblies already called.");
var nativeBinaryPath = IntPtr.Size > 4
? Path.Combine(rootApplicationPath, #"SqlServerTypes\x64\")
: Path.Combine(rootApplicationPath, #"SqlServerTypes\x86\");
_msvcrPtr = LoadNativeAssembly(nativeBinaryPath, "msvcr100.dll");
_spatialPtr = LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial110.dll");
AppDomain.CurrentDomain.DomainUnload += (sender, e) =>
{
if (_msvcrPtr != IntPtr.Zero)
{
FreeLibrary(_msvcrPtr);
_msvcrPtr = IntPtr.Zero;
}
if (_spatialPtr != IntPtr.Zero)
{
FreeLibrary(_spatialPtr);
_spatialPtr = IntPtr.Zero;
}
};
}
There is one caveat with this approach. It assumes your application is the only one running in the worker process that is using the Spatial dlls. Since app pools can host multiple applications the file locks will not be released if another application has also loaded them. This will prevent your deploy from working with the same file locked error.

There are known issues with IIS and file-locks (why they aren't solved yet i dont know).
The question i want to ask however is if you even need to re-deploy these files?
I recognize the file-names and recall them to be system-files which should either already be present on the server or simply not need to be re-deployed.
I am not very experienced when it comes to IIS but i have ran into this problem before and several of my more experienced co-workers have told me that this is as i said a known IIS-issue and i believe the answer to your question is:
Avoid deploying unnecessary files.
try again
Reset website
try again
iisreset

I think what would be the easiest thing to do is to make these dll's as CopyLocal as true. I am assuming these dll's are pulled out from program files folder. Try marking them as copylocal true and do a deployment.Try to stop any IIS local process running in your local machine.

Watch out you don't have one of those new-fangled cloud backup services running that is taking file locks - and also you don't have things open in explorer or a DLL inspection tool.
I think it's kind of ridiculous that MS doesn't make better provisions for this problem. I find that 9 times out of 10 my deployment works just fine, but then as our traffic increases that can become 1 in 10 times.
I am going to solve the problem with :
two applications MySite.A and MySite.B, where only one is running at a time.
I always then deploy to the dormant site.
If there's a problem during the deployment it will never cause the whole site to go down.
If there's a major problem after deployment you can revert back very easily.
Not quite sure how I'm implementing it, but I think this is what I need to do.

Device not receiving C# Windows Push Notifications because channel url incompatible

After many hours of trial, I still fail to send push notifications to my app. This is what I did so far:
Activate the service at https://appdev.microsoft.com
Got the SID, lets call it ms-app://s-1-23-4-12345678901-...-12345678901
Received the client secret, lets call it 12Lwq7526OqNY8iN-aLkwds23451345
In my app I implented the following at some point (simplified):
PushNotificationChannel channel = null;
channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
System.Diagnostics.Debug.WriteLine(channel.Uri);
This prints an url of that kind:
https://db3.notify.windows.com/?token=AgY7AABrfRCVgRV%2ba4DwoDjC2omrnOVwCkdhCrrzlJi6UpIwHzcig6%2fG5xZfnDqU0%2fXoE848ddiqyTaTlSSltp2Dn9Z3qaPsMAyh7kS%2bmlis1%2bwoh%2b%2b4DsAK1yeV1d9G1rUIuFs%3s
I added correct package name, publisher display name and publisher ID to my Package.appxmanifest file
So I thought I was ready for testing push notifications. Using my own implementation of push sharp, fiddler output is the following:
Request:
POST https://db3.notify.windows.com/?token=AgY7AABrfRCVgRV%2ba4DwoDjC2omrnOVwCkdhCrrzlJi6UpIwHzcig6%2fG5xZfnDqU0%2fXoE848ddiqyTaTlSSltp2Dn9Z3qaPsMAyh7kS%2bmlis1%2bwoh%2b%2b4DsAK1yeV1d9G1rUIuFs%3s HTTP/1.1
X-WNS-Type: wns/toast
Authorization: Bearer EgAC4AA1hAZAQMAklDAAEgAAAUe8/AGsK8a/yk78/WEDQf+KUld/nYIvJ51OIoCPgAfwqbl0oo1sPDLhd9ChiO/iLFVzwlTPE3trp9oTkJxNXi0yUrf+FKjRciq7Utek9B/4dxH9lFNy0R5iwdMS0xNS0yLTIyNDgyMDE1NzEtMjczODcxMjkyMy0yMzM3MbsS59ZuQmXCIAFoOiAAAAAAAgzMOTB7OuFIezrhS60gEAAoANS45LjYuMTBiPoPMh3Nj5MAEOp0RhrcMUx6D50AtDuzWE1AAAAAABeAG1zLWiwcDovL3MtTk2Nzk3LTEzOTYwNDkxODYtMjEyODYwMTQ3MS04MDg1MDg2ODUtMzY3NjQyNTk3OQA=
Content-Type: text/xml
Host: db3.notify.windows.com
Content-Length: 138
<toast>
<visual>
<binding template="ToastText01">
<text id="1">This is a test</text>
</binding>
</visual>
</toast>
Answer
HTTP/1.1 403 Forbidden
Content-Length: 0
X-WNS-ERROR-DESCRIPTION: Channel URL incompatible with caller app
X-WNS-MSG-ID: 5FC550364E079585
X-WNS-DEBUG-TRACE: DB3WNS4011533
Date: Mon, 23 Dec 2013 23:58:22 GMT
I found this post Channel URL incompatible with caller app so far which was not really helping
I get the same error using the web service of http://31daysofwindows8.com/push. What can I do here? What could have gone wrong? Please note that this app has not been published yet to the store and I am testing on my local Windows 8.1 installation.

Wow, this is unbelievable. I nearly went nuts, but here is the solution (and explanation):
In the windows app dashboard it says that you can set your app identity manually or automatically. I chose to do it manually (I mean, why not?). But that was a mistake. I quote from microsoft.com dashboard:
Set your app's identity values manually
Open your app's AppManifest.xml file in a text editor and set these attributes of the element using the values shown here.
<Identity Name=" MyName.MyApp " Publisher="CN=*******-****-****-****-************" />
This method did not let me receive push notifications!
The only way to get push notifications (for me) was the following: Try to set the app identity automatically by Visual Studio by calling this menu:
PROJECT -> STORE -> ASSOCIATE APP WITH THE STORE...
This solved my problem.

I was unable to use the "Associate App" approach because the customer wasn't comfortable with giving us their credentails.
What worked for me was to remove the following two elements from the .csproj file of the app:
<PackageCertificateKeyFile>...</PackageCertificateKeyFile>
<PackageCertificateThumbprint>...</PackageCertificateThumbprint>
Do that by either dragging the file into a text editor or unloading the project (using right click) and editing it using the xml editor (again in the context menu).
These elements might have snuck in when we associated our app with our testing app and stayed there when we removed the association and just set the identity as described by andreas.
<Identity Name="..." Publisher="CN=..." />
Edit: Just found out that doing this might break msbuild scripts that build packages. However, building app packages once within Visual Studio created new versions of these elements which then worked for me.

MS documents are a nightmare for me, finally I found what need to do is:
right click on your windows store app solution -> "Store" -> "Associate App with the Store..." -> choose your app name and follow the steps until message "successfully" -> rebuild and run
Despite edit manifest manually by strictly follow the documents, but apparently it's not complete enough.

Using Cordova for Windows, I found out, that even after "Associate App with the Store...", Push Messages failed to be delivered.
The issue was, that the App still had default CordovaApp_TemporaryKey.pfx assigned.
After I've copied new CordovaApp.Windows_StoreKey.pfx to CordovaApp_TemporaryKey.pfx message delivery succeed.

Disabling certificate revocation checking for an application on Windows

I have a .NET 3.5 desktop application that had been showing periodic slow downs in functionality whenever the test machine it was on was out of the office.
I managed to replicate the error on a machine in the office without an internet connection, but it was only when i used ANTS performance profiler that i got a clearer picture of what was going on.
In ANTS I saw a "Waiting for synchronization" taking up to 16 seconds that corresponded to the delay I could see in the application when NHibernate tried to load the System.Data.SqlServerCE.dll assembly.
If I tried the action again immediately it would work with no delay but if I left it for 5 minutes then it would be slow to load again the next time I tried it.
From my research so far it appears to be because the SqlServerCE dll is signed and so the system is trying to connect to get the certificate revocation lists and timing out.
Disabling the "Automatically detect settings" setting in the Internet Options LAN settings makes the problem go away, as does disabling the "Check for publishers certificate revocation".
But the admins where this application will be deployed are not going to be happy with the idea of disabling certificate checking on a per machine or per user basis so I really need to get the application level disabling of the CRL check working.
There is the well documented bug in .net 2.0 which describes this behaviour, and offers a possible fix with a config file element.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
This is NOT working for me however even though I am using .net 3.5.
The SQLServerCE dll is being loaded dynamically by NHibernate and I wonder if the fact that it's dynamic could somehow be why the setting isn't working, but I don't know how I could check that.
Can anyone offer suggestions as to why the config setting might not work?
Or is there another way I could disable the check at the application level, perhaps a CAS policy setting that I can use to set an exception for the application when it's installed?
Or is there something I can change in the application to up the trust level or something like that?

You can specify in code if you want to check the revocation list per application:
ServicePointManager.CheckCertificateRevocationList = false;

In this blog posting (which cites another source) you have two options: disable CRL checking system wide or per app:
Disable CRL Checking Machine-Wide Control Panel -> Internet Options ->
Advanced -> Under security, uncheck the Check for publisher's
certificate revocation option
Disable CRL Checking For a Specific .Net Application See this
Microsoft KB Article: http://support.microsoft.com/kb/936707

What solved the problem for me:
I (think I) had a problem with online revocation before, so I explicitly switched to offline. Due to to warning, I now had to change...
_ = builder.Services.AddAuthentication(CertificateAuthenticationDefaults.AuthenticationScheme)
.AddCertificate(
options =>
{
options.AllowedCertificateTypes = CertificateTypes.All;
options.RevocationMode = X509RevocationMode.Offline;
}
);
... to ...
_ = builder.Services.AddAuthentication(CertificateAuthenticationDefaults.AuthenticationScheme)
.AddCertificate(
options =>
{
options.AllowedCertificateTypes = CertificateTypes.All;
options.RevocationMode = X509RevocationMode.NoCheck;
}
);