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 %LOCALAPPDATA%\Microsoft\MSBuild\15.0\Imports\Microsoft.Common.props\ImportAfter\Sign.props (the file name can be different, but it must be at that location) with this content:
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
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
Get-NetConnectionProfile
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:
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!
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();
try
{
myClient.DoSomething();
myClient.Close();
}
catch
{
myClient.Abort();
// 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:
using System;
using System.ServiceModel;
public class GenericProxy<T> : ClientBase<T>, IDisposable
where T : class
{
public GenericProxy()
: base()
{
}
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:
[assembly: AssemblyKeyName("myKeyName")]
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
<KeyContainerName>myKeyName</KeyContainerName>
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
