Category Archives: programming and related

Programming, software develpment, web development and everything related to writing code

64bit annoyances in resource generation with Visual Studio 2010

Recently, we’ve seen a number of people reporting problems with resource generation in Visual Studio 2010, particularly when they target .NET Framework 3.5 on 64-bit machines.  In this blog post, I will highlight one of the most common errors; when and where it occurs, and how to work around it.  In a later post, we’ll take a look at some other somewhat less common errors, and some background on the differences between the GenerateResource of VS 2008 and that of VS 2010.  

 

Running your development machine with a 64bit operating system is one of the best decisions you’ll make, even it it’s just for having more than 3GB of memory available. But occasionally there are some glitches, like this one with resource generation, but this post from the Visual Studio Blog had put me in the right direction.

Posted via t3mujin’s quick thoughts

Migrating a Visual Studio 2005 Guidance Package to Visual Studio 2010

Visual Studio 2010 has brought the concept of extensions, a brand new set of tools to extend and adapt the software to the needs of each developer.  This is great for Visual Studio users, for having a shiny new Gallery with lots of extensions, but also for addin developers as it makes the development process much easier.

But how about Guidance Automation (the way to go in extending Visual Studio 2005 and 2008)? To have all those guidance packages out there Microsoft released Guidance Automation Extensions and Guidance Automation Toolkit 2010, that allows to building and deploying existing projects as a VSIX package in Visual Studio 2010. But putting an existing guidance package to work in Visual Studio 2010 isn’t a seamless process and requires to migrate it manually, described thoroughly in this guide:

How to Update a Visual Studio 2008 Guidance Package to Visual Studio 2010

Although it’s aimed for Visual Studio 2008 guidance packages it also works for 2005, even if not out of the box. The main glitch is in step 4d while running the UpdateGuidancePackageToVSIX recipe: it won’t update the Version and PublicKeyToken of .vstemplate files because it expects a different version of the Microsoft.Practices.RecipeFramework.VisualStudio assembly, we must edit the WizardExtension element in all .vstemplate files manually (or replace in all files using a an editor like Notepad++) so in the end it each of them looks like this:

<WizardExtension>

Your ads will be inserted here by

Easy AdSense.

Please go to the plugin admin page to paste your ad code.

<Assembly>

Microsoft.Practices.RecipeFramework.VisualStudio, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

</Assembly>

<FullClassName>

Microsoft.Practices.RecipeFramework.VisualStudio.Templates.UnfoldTemplate

</FullClassName>

</WizardExtension>

Along the process some other issues might happen that could make the migrate more complicated:

  • The classes of namespace Microsoft.Practices.WizardFramework.Configuration exist in two assemblies (Microsoft.Practices.WizardFramework and Microsoft.Practices.RecipeFramework.VisualStudio) and if any of these classes is used we’ll have to use an extern alias to resolve the ambiguity,
  • If “The “GenerateMenuResource” task failed unexpectedly (…)” happens double check that the properties of each .vstemplate file are set to Build Action=Content , Copy To Output Directory=Copy if newer, Include in VSIX=True and also that there aren’t any .vstemplate files not included in the project (either include or delete them).

Injecting properties in Ninject 2 without “[Inject]” attribute

Dependency Injection is a great way to remove dependencies while having an lightweight container (a “service locator”) wiring up the application’s components and resolving instances and relationships. But Ninject, one of the dependency injection solutions for .Net, adds another unwanted dependency: to the container itself.
A dependency to Ninject is needed when initializing the container and obtaining entities, although the latest can be minimized using the Common Service Locator library to create an abstraction to most of the currently available dependency injection implementations. But Ninject also adds a dependency to the classes that will be initialized by the container, this is not desired and should be avoided at all cost and these classes shouldn’t be aware how they’ll be instantiated.
Ninject defines an attribute (Inject) used as an hint by the Ninject kernel to know where to inject the instantiated objects; although this attribute is optional for Constructor Injection is mandatory for Property Injection and Method Injection.

// My class where Ninject 
// will create and inject 
// an instance of IWeapon
public class Samurai 
{
    //  This is a Ninject attribute, 
    //  if we switch to another 
    //  DI container the code will break
    [Inject]         
    public IWeapon Context { get; set; }
}

Fortunately Ninject is highly customizable and allows to change that behavior, the plan is to create a custom attribute and configure it so that Ninject can use it the same way it uses the Inject attribute. The usage will be similar but all the dependencies will be to local classes, the custom attribute can be something as simple as this:

public class InjectHereAttribute : Attribute
{
}

The class will now look like this:

public class Samurai 
{
    //  Now there's no external dependency, 
    //  
    //  
    [InjectHere]         
    public IWeapon Context { get; set; }
}

Now Ninject must be configured to use the custom attribute, this can be done by creating an implementation of IInjectionHeuristic that recognizes the custom attribute:

public class CustomInjectionHeuristic : NinjectComponent, IInjectionHeuristic, INinjectComponent, IDisposable
{
    public new bool ShouldInject(MemberInfo member)
    {
        return member.IsDefined(
          typeof(InjectHereAttribute), 
          true);
    }
}

And finally add this behavior to the Ninject Kernel using the Components collection, it will run along the existing components, namely the default implementation of IInjectionHeuristic, which means either the default or the custom attribute can be used.


  
// Add custom inject heuristic
kernel.Components.Add<IInjectionHeuristic, CustomInjectionHeuristic>();
  

on unity injection attributes

Unity is a pretty neat piece of work, it’s a simple and straightforward dependency injection container and it gets the job done, which is all you want from any implementation like this.

If someone’s trying to go beyond the “get an implementation instance for a given interface” examples found in most of the tutorials then proper dependency injection will be the way to go. This means returning the proper instance for the given interface, but also properly the objects that instance needs, and also the objects needed by those objects, and this could go on forever. Unity can do this almost automatically, but to do so it may need hints on how objects should be created, specially to choose the right constructor when multiple are available (by default will choose the fatest of them all).

One of the ways this problem is solved is using an attribute that indicates which constructor should be used (the same is valid for either properties and method calls), as shown below:

public class MyClass
{
  public MyObject(SomeOtherClass myObjA)
  {
    ...
  }

  [InjectionConstructor]
  public MyObject(MyDependentClass myObjB)
  {
    ...
  }
} 

The problem is: Unity, and all other dependency injection containers, want to solve a simple issue: reduce coupling between modules, classes, etc. That’s achieved by removing the dependency to the proper implementation, you only have to know the contract to use (the interface) and the dependency injection container will return the proper implementation, whatever that may be. But, by doing this we’re adding another dependency: to the dependency injection container implementation (like Unity), and while this is reasonable for the class that needs to use the container is not so reasonable for the classes the container will use.

Take the code sample above: MyClass is just a plain class, by adding the InjectionConstructor attribute we’re adding a needless dependency because that class will never use Unity, it will be used by Unity. For me using this can be a design flaw that goes against what dependency injection is supposed to achieve. A safer, but more time consuming, way to get around this is to explicitly configure those dependencies (either in design time or run time) instead of letting Unity try to figure them out.

 

Technorati Tags: ,,,,

Share this: 

…because Agile is more than Daily Scrums

Oh, and it also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.
James Shore: The Decline and Fall of Agile

Doing Daily Scrums, Sprint Plannings and all those Agile related “ceremonies” won’t improve the process in any way, without a proper background (good team communication, choosing the right best practices, etc.) those “ceremonies” will only help to point the team’s flaws.

The Future of WCF

“WCF started with a clear bias towards SOAP, WS-* protocols, and other heavyweight standards that were being popularized at the time but had not been ubiquitously adopted.
(…)
I didn’t believe though that you could force the world to use a single approach for building web services.”

Nicholas Allen

Windows Communication Foundation has to be one of the most interesting pieces of the .Net universe released in recent years, mostly for being a huge improvement over the previous web service model in .Net. So when one the minds behind WCF writes about the framework’s future it’s certainly worth a closer look.

The Future of WCF, Part 1
The Future of WCF, Part 2

A programmer’s fate…

Hero Anti-Pattern

Hero Pattern

One popular solution to the operation issue is a Hero who can and often will manage the bulk of the operational needs. The Hero Pattern can work in a small environment when one individual has the talent and capacity to understand an entire system, including the many nuances required to keep it functioning properly. For a large system of many components this approach does not scale, yet it is one of the most frequently-deployed solutions.

The Hero often understands service dependencies when no formal specification exists, remembers how to toggle features on and off or knows about systems everyone else has forgotten. The Hero is crucial but the Hero should not be an individual.

I believe the best solution to the Hero Pattern is automation. However, it also helps simply to rotate individuals from team to team if the organization has the capacity. In banking, it’s sometimes mandatory to take vacation so any “I’ll just run this from my workstation” activities can be brought to light.

Scalability Worst Practices [InfoQ]

Lately I’ve faced this pattern, or maybe anti-pattern, more times than I ‘d like to, either for lingering around a “hero” or even being one. My experience tells me that Agile practices like Scrum, although never addressing it explicitly, when properly implemented can minimize this problem.

Eclipse Ganymede is out.

The Eclipse Project is home to a quite reasonable amount of sub projects, the list keeps growing every year, so to help the end-user the Eclipse Foundation arranges a simultaneous yearly release of Eclipse and all sub projects. Ganymede is the 2008 release, following Europa in 2007 and Callisto in 2006, and it contains Eclipse’s latest version (3.4).

Eclipse Ganymede

Control Windows Services with Launchy

I’ve been a long-time fan of Launchy, and most of the other application launchers out there, for some time. And now I found out another good use for this neat little tool:

Launchy Utility: Easily start, stop, and restart Windows services [labs.atellis.com]

Technorati Tags: ,