List of C# Compiler Warnings

Generally, you want to fix compiler warnings as they come up, but you may need to suppress some of them for legitimate reasons. A list of warnings and errors can be found here, but there’s no high-level list.
Here is a summarized list of warnings.

 

Warning	Description	More Info
Level 1 Warnings (Severe)
CS0420	‘identifier’: a reference to a volatile field will not be treated as volatile	https://msdn.microsoft.com/en-us/library/4bw5ewxy.aspx
CS0465	Introducing a ‘Finalize’ method can interfere with destructor invocation.	https://msdn.microsoft.com/en-us/library/02wtfwbt.aspx
CS1058	A previous catch clause already catches all exceptions	https://msdn.microsoft.com/en-us/library/ms228623.aspx
CS1060	Use of possibly unassigned field 'name'. Struct instance variables are initially unassigned if struct is unassigned.	https://msdn.microsoft.com/en-us/library/bb384216.aspx
CS1598	XML parser could not be loaded for the following reason: 'reason'. The XML documentation file 'file' will not be generated.	https://msdn.microsoft.com/en-us/library/szfbfb7e.aspx
CS1607	A warning was generated from the assembly-creation phase of the compilation.	https://msdn.microsoft.com/en-us/library/4a0640cd.aspx
CS1616	Option 'option' overrides attribute 'attribute' given in a source file or added module	https://msdn.microsoft.com/en-us/library/0b104xt8.aspx
CS1658	'warning text'. See also error 'error code' The compiler emits this warning when it overrides an error with a warning.	https://msdn.microsoft.com/en-US/library/ft0k10fs.aspx
CS1683	Reference to type 'Type Name' claims it is defined in this assembly, but it is not defined in source or any added modules	https://msdn.microsoft.com/en-US/library/6b351z64.aspx
CS1685	The predefined type 'System.type name' is defined in multiple assemblies in the global alias; using definition from 'File Name'	https://msdn.microsoft.com/en-us/library/8xys0hxk.aspx
CS1690	Accessing a member on 'member' may cause a runtime exception because it is a field of a marshal-by-reference class	https://msdn.microsoft.com/en-us/library/x524dkh4.aspx
CS1691	'number' is not a valid warning number	https://msdn.microsoft.com/en-us/library/7z6tx3wa.aspx
CS1699	Use command line option "compiler_option" or appropriate project settings instead of "attribute_name"	https://msdn.microsoft.com/en-us/library/xh3fc3x0.aspx
CS1762	A reference was created to embedded interop assembly '<assembly1>' because of an indirect reference to that assembly from assembly '<assembly2>'. Consider changing the 'Embed Interop Types' property on either assembly.	https://msdn.microsoft.com/en-us/library/ff183282.aspx
CS1956	Member 'name' implements interface member 'name' in type 'type'. There are multiple matches for the interface member at run-time. It is implementation dependent which method will be called.	https://msdn.microsoft.com/en-us/library/bb882526.aspx
CS3003	Type of 'variable' is not CLS-compliant	https://msdn.microsoft.com/en-us/library/ax5w23a6.aspx
CS3007	Overloaded method 'method' differing only by unnamed array types is not CLS-compliant	https://msdn.microsoft.com/en-us/library/3w1d36e0.aspx
CS3009	'type': base type 'type' is not CLS-compliant	https://msdn.microsoft.com/en-us/library/tdd79w48.aspx
CS4014	Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.	https://msdn.microsoft.com/en-us/library/hh873131.aspx
Level 2 Warnings
CS0108	'member1' hides inherited member 'member2'. Use the new keyword if hiding was intended.	https://msdn.microsoft.com/en-US/library/3s8070fc.aspx
CS0467	Inherited members from different interfaces that have the same signature cause an ambiguity error.	https://msdn.microsoft.com/en-us/library/ms228509.aspx
CS0618	'member' is obsolete: 'text'	https://msdn.microsoft.com/en-us/library/x5ye6x1e.aspx
CS1701	Assuming assembly reference "Assembly Name #1" matches "Assembly Name #2", you may need to supply runtime policy	https://msdn.microsoft.com/en-us/library/2h4x8b08.aspx
Level 3 Warnings (Less Severe)
CS0675	Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first	https://msdn.microsoft.com/en-us/library/wdc6717a.aspx
CS1700	Assembly reference Assembly Name is invalid and cannot be resolved	https://msdn.microsoft.com/en-us/library/ac36c25f.aspx
Level 4 Warnings (Informational)
CS0429	Unreachable expression code detected	https://msdn.microsoft.com/en-us/library/2ch1a3w5.aspx
CS1591	Missing XML comment for publicly visible type or member 'Type_or_Member'	https://msdn.microsoft.com/en-us/library/zk18c1w9.aspx
CS1610	Unable to delete temporary file 'file' used for default Win32 resource -- resource	https://msdn.microsoft.com/en-US/library/z4aytccf.aspx

Configure SourceTree to Rebase by default

Here’s a quick tip for Git for Windows users that are using Atlassian’s SourceTree as their visual interface.

If you’re using git flow as a branching strategy, a good habit to form is to use git pull --rebase when you update your local branch. This technique updates your local branch and then “replays” your changes on top, effectively putting your changes at the head of the branch.

The SourceTree Pull dialog supports this feature with a checkbox, but it’s not enabled by default.

To make this checkbox selected by default:

1. Tools –> Options
2. Git
3. Check the “use rebase instead of merge by default for tracked branches” option

Init Methods are Crap

This title of this post pretty much sums up how I feel about Init methods. Let’s take a look at an example why.

I’ve been on a soap-box yelling at anyone who’ll listen that “work in the constructor” is perhaps the worst thing you can do as a developer. You’ve drank the cool-aid and you have some fairly important initialization logic that needs to be called, so you move the logic out of the constructor and into a separate method. Your code now looks like this:

public class MenuProvider : IMenuProvider
{
    private Array<MenuItem> _menuItems;
    
    public void Initialize()
    {
        // do work to populate menu items, serialize from file, etc...
        _menuItems = // some value;
    }

    public IEnumerable<MenuItem> MenuItems
    {
        get
        {
            return _menuItems;
        }
    }

    public IEnumerable<MenuItem> InActiveMenuItems
    {
        get
        {
	    return _menuItems.Where(i => i.Active == false);
        }
    }

}

It's a contrived example, but in the above code MenuItems will be null and InActiveMenuItems throws an error unless you call Initialize() first. Certainly, there must be a better design than this? (If you answered put the work in the constructor, please come see me after class, I.. uh,.. have something for you.)

Putting the onus on the developer to call methods in a certain order is a very backward approach. You, the class designer, should make it difficult for people to do things the wrong way. We can take on some of that onerous effort inside the class, something like this should work nicely:

public class MenuProvider : IMenuProvider
{
   private bool _isInitialized;
   private object _lock = new object();
   private Array<MenuItem> _menuItems;

   public IEnumerable<MenuItem> GetMenuItems()
   {
        EnsureInitialized();
    
        return _menuItems;
   }

   public IEnumerable<MenuItem> GetInactiveMenuItems()
   {
        EnsureInitialized();

        return _menuItems.Where(i => i.Active == false);
   }

   private void EnsureInitialized()
   {
        if (!_initialized)
        {
            Initialize();
        }
   }
   
   private void Initialize()
   {
        lock(_lock)
        {
            if (!_initialized)
            {
                // do initialization work
                _initialized = true;
            }
        }
   }
}

In this design, I've made a few minor adjustments. For stylistic purposes, I converted the properties into methods because properties look awkward on interfaces. Properties also aren't a good choice if there's work involved in calculating them, so methods feel better here.

Outside of the cosmetic changes, one of the most notable changes is that my Initialize method is now private. I've also added some plumbing logic to ensure that the Initialize method only does work the first time it's called, and since this is good defensive programming, this might have already existed and shouldn't be a surprise.

What should stand out to you, is that each method is responsible for ensuring that the initialization logic is called on the user's behalf using the EnsureInitialized method before doing any other work. Some developers may grumble that this seems like a simple thing to forget when adding new methods and thus has potential for silly bugs. That’s fair, but because the API for the class has been simplified the tests to catch this should be much easier to write and find.

Alternatively, we can take this approach further by splitting the concerns into smaller parts. One part could read the file contents and the other part could be responsible for serving the data to consumers. This is effectively just moving the Initialize method to another class. Something like this:

public class MenuProvider : IMenuProvider
{
    private MenuReader _reader;

    public MenuProvider(MenuReader reader)
    {
        _reader = reader;
    }

    public IEnumerable<MenuItem> GetMenuItems()
    {
        return _reader.GetAll();
    }

    public IEnumerable<MenuItem> GetInactiveMenuItems()
    {
        return _reader.GetAll().Where(i => i.Active == false);
    }
}

public abstract class MenuReader
{
    public abstract IEnumerable<MenuItem> GetAll();
}

public class StaticFileMenuReader : MenuReader
{
    private Array<MenuItem> _items;

    public IEnumerable<MenuItem> GetAll()
    {
        if (_items != null)
        {
            // do serialization work
        }
        return _items;
    }
}

This small change greatly simplifies the MenuProvider and the extra step to move the serialization logic into another class may seem familiar to others as a Repository pattern. The repository pattern in this example also affords us additional test flexibility as the file-system can be abstracted away with a test-double.

To sum up, it seems a bit odd to design a class that requires methods to be called in a specific order. Initialization in general is something that the class designer should be well equipped to handle, so don’t push this responsibility to others – a few small changes to your class makes your code more usable, responsive and easier to test.

MEF Hacks: Constructors with parameters

Often, there’s a need to register an object into your dependency container that takes constructor arguments. There are a few ways to accomplish this with MEF.

You’re mileage will vary, but my favorite approach is a bit of a hack that leverages a lesser-known feature of MEF: Property Exports.

public class ComplexObjectExportFactory
{
    [Export]
    public MyComplexObject ComplexObject
    {
        get
        {
            return new MyComplexObject("config.xml");
        }
    }
}

This "simply works" and doesn't require you to do anything intrusive like sub-classing a dependency or registering named parameters on application start-up. The technique is especially useful if you need to provide any kind of conditional logic based on settings and it can even build upon other MEF registered parts, for example:

internal class ComplexObjectExportFactory
{
    private readonly IApplicationSettingsProvider _settings;
    private readonly IEventAggregator _eventAggregator;

    [ImportingConstructor]
    public ComplexObjectExportFactory(
            IApplicationSettingsProvider settings, 
            IEventAggregator eventAggregator)
    {
        _settings = settings;
        _eventAggregatore = eventAggregator;
    }

    [Export]
    public MyComplexObject ComplexObject
    {
        get
        {
            string configFile = _settings.GetSetting("ComplexObjectConfigFile");
            int timeout = _settings.GetSetting<int>("ComplexObjectTimeoutSeconds");
            
            return new MyComplexObject(_eventAggregator, configFile, timeout);
        }
    }
}

The only real down-fall to this overall approach is that the ComplexObjectExportFactory will never have any usages, so tools like Resharper will think this is dead-code, but this can be solved with a few well placed #pragmas and some comments. The other reason this feels like a hack, and this is more of an esthetics or stylistic difference, is that this feels like it should be a method (eg, factory.Create()) but MEF treats exported methods very differently.

Despite the awkwardness of this class, I’d prefer this to sub-classing third-party dependencies or bloating the bootstrapper with additional initialization logic. Maybe you think so too?

Happy coding.

Application Services for WPF Applications

Suppose you’re building a WPF application and have a number of actions that you want to perform on application start-up. Here’s a pattern that I’ve used successfully for the last few years that works with Caliburn.Micro or other MVVM frameworks…

If you're using Caliburn.Micro, the framework provides a Bootstrapper as an entry point to your application and the overridable Configure method is a great place to initialize your application-specific services.

You might be tempted to do something like this:

protected override void Configure()
{
    Container = new CompositionContainer(
       new AggregateCatalog(AssemblySource.Instance.Select(x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));

    var batch = new CompositionBatch();

    // initialize Caliburn.Micro services and register with container
    EventAggregator = new EventAggregator();

    batch.AddExportedValue<IWindowManager>(new WindowManager());
    batch.AddExportedValue<IEventAggregator>(EventAggregator);
    batch.AddExportedValue(Container);
    Container.Compose(batch);

    // initialize and register all my custom components
    var myService = new MyService();
    myService.Configure("config.xml");
    // repeat for all other services...

}

While this strategy works for one or two services, you'll find that as you add additional services your Bootstrapper logic becomes quite bloated and simply owns too many responsibilities.

To simplify things, let's define a simple interface that describes all of our application services:

public interface IApplicationService : IDispose
{
    void Initialize();
}

And now we can generically initialize all services that implement this interface:

protected void Configure()
{
   // snip...
   Container.Compose(batch);

   InitializeApplicationServices();
}

protected void InitializeApplicationServices()
{
   var services = Container.GetExports<IApplicationService>();
   foreach (Lazy<IApplicationService> exportedService in services)
   {
       IApplicationService service = exportedService.Value;
       Log.InfoFormat("Initializing IApplicationService:{0}.", service.GetType().Name);
       service.Initialize();
   }
}

protected override OnExit(object sender, EventArgs e)
{
    Container.Dispose();

    base.OnExit(sender, e);
}

[Export(typeof(IApplicationService))]
public class MyApplicationService : IApplicationService
{
    private MyService _service;        

    public void Initialize()
    {
       _service = new MyService();
       _service.Configure("config.xml"); 
    }

    public void Dispose()
    {
       GC.SuppressFinialize(this);
       Dispose(true);
    }
    protected virtual void Dispose(bool disposing)
    {
       _service.Dispose();       
    }
}

There! That’s a lot cleaner. Now the Bootstrapper doesn’t know anything about our services and we can add new services without having to further extend this class. There are a few additional benefits:

1. If you’re using MEF, all classes that are export IApplicationService are singletons by default.
2. All services have a predefined start (Initialize) and end (Dispose), thereby avoiding work that is often put in the constructor.
3. Perhaps not obvious, but if you’re using MEF, calling Container.Dispose() when the application exits automatically calls Dispose on all our application services, too.

So there you have a basic initialization routine for all your background services. My next few posts will demonstrate how to really take advantage of this pattern.

P.S: Astute readers of my blog might recognize that I'm using an Initialize() method which I've called out as a bad habit on my On Notice Board. While “Init methods” is high on my list, the context here is different. In this context, the only method I know about is Initialize(), whereas the “Init method” smell is a required method that must be called before calling other methods on the same class. I’ll blog about how to remove Init methods later.

Debugging Google Authentication + Azure MobileServices

Let’s say you’re building a mobile application using Azure MobileServices with Google Authentication but you want to debug and run the solution on your local developer environment. This post will walk you through setting up your local environment and provide an example of how to test your local services.

Before we start, the getting started documentation on how to add Google Authentication to your mobile application is pretty good, and if you follow the samples it’s fairly easy to get up and running. For the purposes of this post, I’m not going to repeat those setup instructions so if you’re trying to get it running you should definitely read this article before reading any further. I should also point out that I’m using a .NET Backend for my MobileService, so there are a few minor variances if you’re using Node.

Step 1: add your Google Client ID and Client Secret to your web.config. By default, the configuration for your MobileService is defined through the Azure MobileServices dashboard so local values in your web.config are ignored in the Azure environment. In order to debug Google Authentication locally, simply provide values for MS_GoogleClientID, MS_GoogleClientSecret in your web.config:

Step 2: modify the settings of your Google Project to support your local environment. At this point, attempts to authenticate in your local environment will fail because the Redirect Url for your local environment doesn’t match the settings defined in the Google Developer Console. Fortunately, the good folks at Google had the smarts to allow multiple redirect URLs. Simply provide the URL of your local developer environment. In my case, I’m running this in IIS Express and I’m using the URL http://localhost:61915

1. Navigate to https://console.developers.google.com/project and select your Project
2. In the Credentials section, click the Edit Settings button and add your local URL to the Authorized Redirect URIs.

Testing it out

So we’ve made a few simple changes and now it’s time to test it out.

1. Navigate to http://localhost:61915/login/google in your browser.
2. If all things are properly configured you should be redirected to Google’s oAuth page to provide consent to your application. Provide consent, dummy.
3. Your browser will be redirected to a special URL (http://localhost:61915/done#token=<json-data>).
4. Copy the URL and decode it. I like to use this online tool http://meyerweb.com/eric/tools/dencoder/
5. Once decoded, make note of the authentication-token.

1. Now using your favourite REST client (mine's the Chrome Advanced REST Client), supply the header X-ZUMO-AUTH: + your auth token and call any web-API method that would require authentication.

Cheers!