Visual Studio 2017 version 15.6 currently has a problem if a project signs an assembly with the AssemblyKeyNameAttribute: https://developercommunity.visualstudio.com/content/problem/209811/strong-name-signing-with-a-key-installed-in-a-cont.html
One suggested workaround is to add this line in the project file:
If you have many projects and don't want to include this in every project file, you can create a system-wide configuration for all projects. Create the file
(the file name can be different, but it must be at that location) with this content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
The workaround will be included in every build on that machine (for the current user account). Since I don't work on .NET Core projects, I don't know whether this breaks signed .NET Core builds.
Today I imported a snk file to a key container as an Administrator and wanted to give another (non-admin) user access to that key container, so that he can sign assemblies with it.
I couldn’t find an easy solution. But I couldn’t believe that Microsoft doesn’t have a native tool for this and so I tried a solution, which is meant for ASP.NET: In a console I typed
aspnet_regiis.exe -pa <Key container name> <Username>
And it worked
Sometimes I have a virtual machine running Windows Server 2012 and can’t reach some of its services because I allowed their ports only for private networks in the Windows Firewall. Then I see that the network connection has the public profile. This is the easiest way I found to change the profile:
Open a PowerShell with administrator privileges and type
You should get a list of network interfaces:
Name : Network
InterfaceAlias : Ethernet
InterfaceIndex : 12
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic
Name : Network #2
InterfaceAlias : LAN-Connection
InterfaceIndex : 17
NetworkCategory : Public
IPv4Connectivity : LocalNetwork
IPv6Connectivity : NoTraffic
You see that the second network is a public network. Use the InterfaceIndex 17 and enter:
Set-NetConnectionProfile -InterfaceIndex 17 -NetworkCategory Private
Now it is a private network!
Today one of my colleagues wanted to change his password in Windows Server 2012 R2 via a Remote Desktop Connection.
On a local systems you can press CTRL+ALT+DEL to select “Change password”. Obviously you can’t send this key combination through a Remote Desktop Connection. Solution: Press CTRL+ALT+END!
There aren't many breaking changes between .NET 4 and .NET 4.5, but after reading http://blogs.msdn.com/b/webdev/archive/2012/11/19/all-about-httpruntime-targetframework.aspx I was interested how the compatibility layer would react if the main assembly is compiled for .NET 4.5 and a referenced assembly for .NET 4.
I tested it with the List<T>.ForEach method in the blog post, and it acted like I thought it would: The main assembly specifies the compatibility level. If the main assembly is compiled for .NET 4.5, all referenced assemblies are also executed using .NET 4.5, even if they are compiled for .NET 4.
When a WCF client calls a service and the call throws an exception (no FaultException, that's fine), then calling Close() or Dispose() on that client will throw another Exception because the client is in the faulted state. The correct way to "dispose" or cleanup a faulted client is to call Abort(). This means that we can't embed the WCF client in a using-statement because that will always dispose the client.
The correct way would be
ServiceClient myClient = new ServiceClient();
// error handling or throw;
Because some of my projects use a lot of WCF calls, this pattern is too tedious for me. Instead I wrote a simple wrapper:
public class GenericProxy<T> : ClientBase<T>, IDisposable
where T : class
if (State == CommunicationState.Faulted)
public T Service
The only drawback is that instead of writing myClient.DoSomething() now I have to write myClient.Channel.DoSomething():
using (GenericProxy<IService> myClient = new GenericProxy<IService>())
This article is a reference for me since I have to look it up all the time.
Since .NET 1.0 I prefer to sign my assemblies and to use a key container with a AssemblyKeyNameAttribute instead of having to define the path of a key file in each assembly:
Starting with .NET 2.0/Visual Studio 2005 this generates the compiler warning CS1699 (or an unnumbered warning for VB.NET). For my projects I always enable "Treat warnings as errors". For C# I can add 1699 to the suppressed warnings in the project settings, but I can't find a way to suppress the warning in the VB.NET project settings.
Instead I have to edit the .vbproj-file with a text editor and add somewhere in the first PropertyGroup element the line
Unfortunately Microsoft didn't add a project setting to use assembly key containers.
After installing the XML-RPC plug-in, I couldn't get Windows Live Writer to insert or update blog entries. After a week of trying and debugging I found out that the plug-in uses a boolean where serendipity expects a string.
In the file /plugins/serendipity_event_xmlrpc/serendipity_xmlrpc.inc.php I just had to change line 1600 from
$entry['moderate_comments'] = serendipity_db_bool($serendipity['moderateCommentsDefault']);
$entry['moderate_comments'] = serendipity_db_bool($serendipity['moderateCommentsDefault']) ? 'true' : 'false';
Additionally I had to create the media directory "Windows-Live-Writer" in the Administration panel.
Funny, that my .NET blog starts with a PHP-related post