Running unit test on a TeamCity is usually not a big problem but a couple of days ago I noticed I very strange behaviour.
The number of tests executed on the build server was much smaller than the number of tests running on my local machine but TeamCity did not report any errors. After digging into the build log, I noticed this exception in the log files:
System.Runtime.Serialization.SerializationException: Unable to find assembly 'FakeItEasy, Version=22.214.171.124, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c'.
The only noticeable difference between the execution on TeamCity and my local machine was that locally I used the ReSharper test runner and on the build server xunit.console.exe was used to run the test.
When trying to run the tests with xunit.console.exe on my local machine I could reproduce the error.
For some unclear reason, XUnit was not able to load the FakeItEasy assembly that was located in the bin folder of the test assembly. The only workaround I found was to copy the FakeItEasy assembly to the folder of xunit.console.exe. After doing this, the number of tests on my local machine and on TeamCity matched again.
This is not really a satisfying solution, but I couldn’t find a better solution. Did someone find a proper solution for this problem?
RavenDB becomes more and more popular among .NET developer. The simple to use C# Api makes it a good choice for many project that require a fast persistence layer.
The JSON that is stored, can be customize using JSON.NET attributes. But sometimes you annotate your data POCOs and nothing happens e.g.
- You put [JsonIgnore] on a property but it still appears in the created JSON
The reason is simple: The RavenDB team decided to put a copy of JSON.NET in the RavenDB dll and only the attributes from this “special” namespace are used for the JSON handling. So if you want to customize the JSON in the database, always use attributes from the Raven.Imports.Newtonsoft.Json namespace.
Recently, I installed a new laptop with Visual Studio and the “normal” tool chain. While doing this, I encountered a strange error when installing the .NET Core tools.
Setup has detected that Visual Studio 2015 Update 3 may not be completely installed. Please repair Visual Studio 2015 Update 3, then install this product again.
However, repairing Visual Studio did not solve the problem. Luckily, I found this StackOverflow post. The problem could easily be solved by starting the setup on the command line with this command:
Today I had a SharePoint installation that started to throw errors when opening the User Profile Service Application. After examining the ULS log I noticed this log entry:
Requested registry access is not allowed.
So something with the permissions in the registry seemed to be wrong. I manually browsed through the registry settings and compared them to another, working installation but I couldn’t find anything. Luckily I stumbled across this cmdlet: Initialize-SPResourceSecurity I ran the cmdlet and everything started to work fine again.
I was setting up a new build server for a .NET project as I have done several times before. It was a TeamCity build server but that is not important for this problem. When trying to build my solution I got this error:
error CS0012: The type 'IEnumerable<>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Locally the solution compiled just fine. After some research I found some hints that installing the Targeting Pack for my .NET Framework version solves the problem.
I downloaded and installed the target pack for .NET 4.6 from here. Immediately the problem was solved and the solution compiled without any problems.
It compiled locally because the missing DLL that is installed by the Targeting Pack is also installed by Visual Studio. This is just another reason to think about the “no Visual Studio on the build server” rule.
Recently I had a SharePoint installation that stopped writing log files without any clear reason. Restarting the timer service or the whole server did not solve the problem. The only thing I noticed was this entry in the event viewer:
Tracing Service failed to create the trace log file at location specified in SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\WSS\LogDir. Error 0x0: The operation completed successfully. . Traces will be written to the following directory: C:\Users\SVCSPD~3\AppData\Local\Temp\.
Something seemed to be wrong with the log directory but the folder and its permissions looked totally normal. So I opened the Monitoring Settings (Central Admin -> Monitoring -> Configure diagnostic logging), change the path of the trace log to c:\temp and back to its normal location. As soon as I saved the second change, log files started appearing again.
Recently, I was cleaning up an existing Selfhost Owin Asp.NET Web Api project. After removing some seemingly unused references the project crashed when starting the api.
Exception was this:
The server factory could not be located for the given input: Microsoft.Owin.Host.HttpListener
The solution was quite simple: I removed the NuGet package that contains the HttpListener because there is no direct reference to it but Owin still needs the package to start. So just add the NuGet package: Microsoft.Owin.Host.HttpListener again and everything works as before.