Server Collection cannot be empty - Windows Server AppFabric 1.1 - appfabric

I get this error when i use multiple dataCacheClients. Ive seen this question and this msdn question but at the time of AppFabric 1.0, multiple dataCacheClients were not possible. Microsoft added this feature in AppFabric 1.1 (see changelog), which I'm using currently. Any ideas on why I get this error? Here's my config file:
<configuration>
<configSections>
<section name="dataCacheClients"
type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core"
allowLocation="true"
allowDefinition="Everywhere"/>
</configSections>
<dataCacheClients>
<!--client 1 for caching-->
<dataCacheClient name="dataCacheClient1">
<localCache isEnabled="false" sync="NotificationBased" objectCount="100000"/>
<clientNotification pollInterval="5"/>
<hosts>
<host name="!2345623ghf1.fg.com" cachePort="22233"/>
</hosts>
<securityProperties mode="None" protectionLevel="None" />
<transportProperties maxBufferPoolSize="2147483647" maxBufferSize="2147483647" channelInitializationTimeout="60000" receiveTimeout="900000"/>
</dataCacheClient>
<!-- client 2 for session -->
<dataCacheClient name="dataCacheClient2">
<localCache isEnabled="false" sync="NotificationBased" objectCount="100000"/>
<clientNotification pollInterval="5"/>
<hosts>
<host name="!2345623ghf2.fg.com" cachePort="22233"/>
</hosts>
<securityProperties mode="None" protectionLevel="None" />
<transportProperties maxBufferPoolSize="2147483647" maxBufferSize="2147483647" channelInitializationTimeout="60000" receiveTimeout="900000"/>
</dataCacheClient>
</dataCacheClients>
<system.web>
<compilation debug="true" targetFramework="4.0">
</compilation>
<sessionState
mode="Custom"
customProvider="AppFabricCacheSessionStoreProvider">
<providers>
<add name="AppFabricCacheSessionStoreProvider"
type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
cacheName="default"
dataCacheClientName="dataCacheClient2" />
</providers>
</sessionState>
NOTE:
I'm using the DLL's found in .\Program Files\AppFabric 1.1 for Windows Server
More Error details :

I was finally able to get it working. There were some rudimentary but stupid mistakes I committed. Hopefully someone with the same issues would be able to get some guidance on this by my answer. The mistakes I committed/how it was rectified :
1) Check the DLL's CLR version
Always, I mean, always check the version of the DLLs you're using to refer in your consuming client. The DLLs to look out for are :
Microsoft.ApplicationServer.Caching.Core.dll
Microsoft.ApplicationServer.Caching.Client.dll
Microsoft.WindowsFabric.Common.dll
Microsoft.WindowsFabric.Data.Common.dll
Microsoft.Web.DistributedCache (this was what was causing me problems - I had an older version added in my solution; there's no need to refer this, just having this DLL in the same folder as the Caching.Core and Caching.Client is enough)
A good (or rather fail-proof) way to get the latest DLLs is to download & install Appfabric and get the DLLs from .\Program Files\AppFabric 1.1, add it in a folder inside your project and refer it from there.
2) DataCacheFactory must have a reference to what dataCacheClient its referring to
Just like how AppFabricCacheSessionStoreProvider must contain a dataCacheClientName attribute to refer to a specific cluster put in dataCacheClient, DataCacheFactory init in code must also contain a reference to the dataCacheClient which is gonna take care of caching :
DataCacheFactory _factory = new DataCacheFactory(new DataCacheFactoryConfiguration("dataCacheClient1"))
Thanks to everyone who helped in solving this issue!

I had this problem on one of our development machines and it was ultimately found to be installation of Windows Server AppFabric. My configuration was totally correct. The same configuration worked on all machines except one and once we un-installed Windows Server AppFabric from that machine and installed Microsoft AppFabric 1.1 version, the issue was resolved.
I'm also using AppFabric to store Asp.NET SessionState.

Related

Failing to start Windows service after a MajorUpgrade with WiX

I have a pretty straight forward WiX project. Nothing fancy. When trying to perform a MajorUpgrade over an existing installation, it is unable to start the service and inevitably rolls back to the previous version and starts the service just fine. I have removed the Start="install" and manually started the application successfully, so I know it's not a dependency issue.
I have searched endlessly and found no answers to my problem.
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallFinalize" />
My service install:
<ServiceInstall
Id="ServiceInstaller"
Type="ownProcess"
Name="LsdnService"
DisplayName="Lsdn Service"
Description="Placeholder for now."
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="normal"/>
<ServiceControl Id="StartService" Start="install" Stop="both" Remove="uninstall" Name="LsdnService" Wait="yes" />
I dumped the MSI log to a file and got this error but it is quite vague.
MSI (s) (18:48) [22:41:27:349]: Note: 1: 2205 2: 3: Error
MSI (s) (18:48) [22:41:27:349]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1920
There are some registry modifications during an installation. The installer attempts to read from the registry and inherit the already existing values.
<Property Id="LSDNADDRESS" Value="127.0.0.1">
<RegistrySearch Id="LsdnAddressProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnAddress" Type="raw" />
</Property>
<Property Id="LSDNPORT" Value="9920">
<RegistrySearch Id="LsdnPortProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnPort" Type="raw" />
</Property>
<Property Id="LSDNKEY" Value="6f380b07-0b54-4904-8303-95d1ec45d453">
<RegistrySearch Id="LsdnKeyProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnKey" Type="raw" />
</Property>
Debugging Results: Following a lot of debugging (by original poster - OP) this turned out to be a known MSI issue described here:
https://wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz-when-using-type-integer. Nice search work.
What is in a DWORD? (a REG_SZ apparently): Essentially MSI "converts" a DWORD value found via a RegistrySearch
operation to a formatted string - REG_SZ - during upgrade
installations (could be more involved too). This causes services that
expect a DWORD value to fall over on startup during major
upgrades. A very exotic error.
Workaround: One can try to "solve" this problem by making the service code capable of reading both DWORD and REG_SZ.
This yields a more robust solution than solving the problem in a
custom action since it is a "permanent" fix as long as the code is in
there (and the presence of the code alerts other developers about the
problem). Or maybe use only REG_SZ?
Quick Checks: Check the service password and login - obviously. Anything in the
Event Viewer? Windows Key + Tap R + eventvwr.msc + Enter. How to use the Event Viewer to troubleshoot problems with a Windows Service. Perhaps you can try to do a folder diff on the before and after folders and see if you see something unexpected in
the config files? Naturally there will be lots of binary
differences, but check the text files (also encoding). Check the MSI log file
again and search for "value 3" as described here: Tips For Checking MSI Log
Files. Manually copy the new files in place and attempt to start the service via the services.msc applet.
Service Experts: Windows Services Frequently Asked Questions (FAQ). Content seems to be up to date - at face value at least.
These guys claim to be experts on services. I have no idea who they
are.
Look in the "Errors" section in the link above. Here are some
extracts:
1053: The service did not respond to the start or control request in a timely fashion
Why doesn't my Windows Service start automatically after a reboot?
1069: The service did not start due to a logon failure
Generic Check Lists: If none of the above does anything, maybe try these "torpedoes full spread" check-lists (just ideas to start debugging):
Desktop applicaton not opening after installation in client system
Windows Application Startup Error Exception code: 0xe0434352
General Purpose Debugging: Throwing in some general-purpose debugging approaches.
Custom Action Debugging: WIxsharp debug custom action in console
Dependency Scanning: Which winform project files should be packed up into the installer
Some Further Links:
C# Debug folder when copied to another location does not run the exe
wix service install not enough permission
How exactly does the WiX 'Service Install' work internally?
WiX Toolset PermissionEx Problem - App Does Not Run After Installation
It certainly could be a dependency issue. For example, GAC / WinSXS files don't get installed into the GAC until the commit phase which is after StartServices.
I would leave the Start="Install" in and while it's sitting at the failed to start prompt inspect the state of the machine and debug the service start manually. I bet you'll find something missing.

Nugetserver onpremise unable to run due to newtonsoft.json version

Target set as .net 4.6 in a vs2015 environment. All fetch and built no errors.
Used https://www.hanselman.com/blog/HowToHostYourOwnNuGetServerAndPackageFeed.aspx and MS doco as reference.
When run under IIS, shows error below
How do I resolve this ?
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.7.2106.0
NB: Version on the Newtonsoft.Json.dll file is 9.0.1.19813
web.config has these 2 lines, do I need to make this and nugget.dll.config have newVersion="9.0.2.0" say ?
< assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
< bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.1.0" />
I have it working, what I did was change the default project of "nuget" to "nugetwebserver" and adjusted the assemblies and module name.
Then did a fresh compile. I suspect the poor choice of name caused some conflict with the some setting seeing by nuget.server project was called ..
Interestingly the http://server/nugetserver2.7/nuget would render in IE
http://server/nugetserver3.1/nuget asks me if I want to download the content. The content being the same as the rendered page for 2.7..

TFS2015 503 service unavailable using .runsetting unit test file

In short, using a .runsetting unit test file in a build step on TFS 2015 results in a 503 Service Unavailable exception.
After extensive searching and testing on a new TFS 2015 installation (as also described in TFS2015 new install, 503 Service Unavailable), I may have found the problem.
We are using .runsettings files as described on https://msdn.microsoft.com/en-us/library/jj159530.aspx, in a 'Visual Studio Test' build step on our new TFS2015 installation, as soon as the VSTest.console.exe is called, the next three application pools on the TFS server crash, resulting in a 503 Service Unavailable error:
DefaultAppPool
Microsoft Team Foundation Server Application Pool
Microsoft Team Foundation SErver Message Queueu Application Pool
First my .runsetting file was kind of large, but i did try the next one (I think as small as possible):
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations for data collectors -->
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<!-- Match assembly file paths: -->
<ModulePaths>
<Include>
<ModulePath>.*\.dll$</ModulePath>
<ModulePath>.*\.exe$</ModulePath>
</Include>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
<ModulePath>.*fluentassertions.*</ModulePath>
<ModulePath>.*\.test\.dll$</ModulePath>
</Exclude>
</ModulePaths>
</CodeCoverage>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
When using this one, the app pools crashes. Even if i remove the part entirely, it will not work.
As soon as the next line is called (taken from the log lines of the build step), the app pools crashes.
Executing C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\Microsoft.QualityTools.Testing.Fakes.dll" "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll" "D:\TfsAgents\Agent1\_work\2\s\[...]\Release\MyClassLib.dll" /Settings:"D:\TfsAgents\Agent1\_work\2\s\[...]\test.runsettings" /EnableCodeCoverage /logger:trx
If you look at the DataCollector tag in the .runsettings file, you see the version is set to 14.0.0.0. If you look at the page of Miscrosoft, they state that it should be 11.0.0.0, but also this version does not work. I thought it might be that version 11.0.0.0 was wrong, so I opened the dll with Telerik JustDecompile, and saw that the 'real' version was 14.0.0.0, so I put that version into the runsetting-file. But no luck.
So for now I'm just remove the runsetting file from the definition of the build, which unfortunately results in a wrong code coverate percentage.. So hopefully someone might have the answer for this.
This problem is limited to the specific runsettings file when used with build agent running on the same machine where IIS server is hosting TFS. There is a workaround available. Within DataCollectors->Configuration->CodeCoverage tag in runsettings file you can add following xml tags with given values :
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>false</CollectAspDotNet>
This should solve the issue, and also its recommended that in future if you are using runsettings file with Code coverage in Data Collector then these tags should be added.

TFS Not all tests are run although the build is green

For some reason about a quarter of our tests is not being run on TFS, build ends up green but reports only 3/4 saying all tests have passed.
I guess the problem is in some tested async code that perhaps crashes the test runner or keeps running on its own. Locally in VS all tests are passing fine.
Is there any way to enable crash dumps on TFS or how should I address this problem?
EDIT: In TFS web interface the Summary says "All 2217 tests passed" but in Diagnotics section, under the passed tests it says "Test run completed. 3228 tests executed" ...still not all (cca 3450 passing locally in VS2015)
I checked last builds on the server but as far as the history goes, they were already failing then (always different amonut have passed). So I can't trace that.
I also ran tests with vstest.console.exe and all is fine except 5 failed on long filepath (I disabled those with Ignore attribbute to no avail)
Edit by the bounty starter:
Sorry for the text in bounty box. Didn't think that line breaks would be swallowed. Providing the same text here.
I have exact same situation. Say I have 100 tests, but only say 60 are finally in the .trx file (say 50 passed and 10 failed). It would be great to solve this issue. Thanks!
<Target Name="CoreTestConfiguration">
<Exec Command=""C:\Program Files\dotnet\dotnet.exe" vstest /Blame /Diag:"$(SolutionRoot)##########################\bin\Release\diag.txt" "$(SolutionRoot)###########################\#################s.dll" /logger:trx;LogFileName="$(SolutionRoot)\#################################\Tests\bin\Release\TestOutput.trx" /Settings:"$(SolutionRoot)\############################################ests\bin\Release\#################sts.runsettings""
ContinueOnError="true"/>
</Target>
<RunSettings>
<RunConfiguration>
<TestSessionTimeout>4400000</TestSessionTimeout>
<TestTimeout>342000</TestTimeout>
<TargetPlatform>X64</TargetPlatform>
<TargetFrameworkVersion>
.NETCoreApp,Version=v2.0
</TargetFrameworkVersion>
<!-- same with net461: but different count of tests in final trx -->
<!-- <TargetFrameworkVersion>
.NETFramework,Version=v4.6.1
</TargetFrameworkVersion> -->
<DesignMode>False</DesignMode>
<CollectSourceInformation>False</CollectSourceInformation>
</RunConfiguration>
<LoggerRunSettings>
<Loggers>
<Logger friendlyName="blame" enabled="True" />
<Logger friendlyName="Console" uri="logger://microsoft/TestPlatform/ConsoleLogger/v1" assemblyQualifiedName="Microsoft.VisualStudio.TestPlatform.CommandLine.Internal.ConsoleLogger, vstest.console, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" codeBase="C:\Program Files\dotnet\sdk\2.1.503\vstest.console.dll" enabled="True" />
</Loggers>
</LoggerRunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="blame" enabled="True">
<Configuration>
<ResultsDirectory>
############################\bin\Release
</ResultsDirectory>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
which version Test Framework are you using?
It seems you want to build/run a dotnet core application.
In my opinion xunit works fine with dotnet core 2.x.
There is also a new version of MS Test framework available which has some interesting improvements. I read that in one of the latest dotnetpro article.
see also
Article, dotnetpro (GER)
Hopefully this will help you to solve this issue,
See ya
Leonhard

Launch x86 or x64 MSI from MSBuild bootstrapper - newb

I don't have much of a programming background, but I have been using Wix to build very basic installations for several years, usually consisting of a browser shortcut with an icon file (The desktop shortcut simply opens 32-bit Internet Explorer to a specific URL). The clientele that use my installers don't usually know about their system and it appears the time has come where I can create a bootstrapper that will run 1 of the 2 .msi files, one for x86 & one for x64. The problem is that the Wix help documentation out there assumes a certain level of knowledge about programming and/or Wix and I need "for dummies" level of help. Using code snippets from Rob's answers to an earlier post here (similarly titled) and a post on another site, I have this in my .wxs:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="Intermountain SecureAccess Desktop Icon Installer" Version="1.0.0.0" Manufacturer="Intermountain Healthcare" UpgradeCode="61b75a8f-67f6-43a1-beb9-1a0be426b5a6">
<BootstrapperApplicationRef Id='WixStandardBootstrapperApplication.HyperlinkLicense' />
<Payload SourceFile="86IHCSAHCO.msi"/>
<Payload SourceFile="64IHCSAHCO.msi"/>
<Payload SourceFile="C:\Program Files (x86)\WiX Toolset v3.7\SDK\Microsoft.Deployment.WindowsInstaller.dll"/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id='Netfx4Full' />
<MsiPackage SourceFile="IHCSAHCO.msi" Id="InstallationPackageId" Cache="yes" Visible="no"/>
<MsiPackage InstallCondition='NOT VersionNT64' SourceFile='86IHCSAHCO.msi' />
<MsiPackage InstallCondition='VersionNT64' SourceFile='64IHCSAHCO.msi' />
</Chain>
</Bundle>
</Wix>
The goal is to create a single .msi (or .exe) called IHCSAHCO.msi which contains the 2 msi packages 86IHCSAHCO.msi & 64IHCSAHCO.msi and then simply runs one or the other depending on the environment. When I run the batch file (called Burn.wxs) with this in it...
set WIX_ROOT=%programfiles(x86)%\WiX Toolset v3.7\bin
del /q /f *.wixobj *.msi
call "%WIX_ROOT%\candle.exe" Burn.wxs
call "%WIX_ROOT%\light.exe" Burn.wixobj -sice:ICE38
pause
...here is the error:
Burn.wxs
C:\PATH\Burn.wxs(8) : error CNDL0104 : Not a valid source file; detail: The 'Bundle' start tag on line 3 position 4 does not match the end tag of 'BootstrapperApplicationRef'. Line 8, position 7.
I feel as though I am close and am hoping one of you could take a quick peek at the code and give suggestions. It would be much appreciated...
Thanks!
RHH
Your opening BootstrapperApplicationRef element on line 4 is an empty element - it shouldn't end in />.
What are you using to edit your files? Pasting your file into Notepad++ and turning on XML highlighting identified the problem pretty quickly.