Tag Archives: .net

Shared links for the past week

In a week where the world was suppose to end and dominated by Instagram’s new Terms of Service, my handpicked links:

shared with delicious

Links for 2012-11-29

Some of the most interesting links I found for 2012-11-29


shared with delicious

Links for 2012-05-2

Some of the most interesting links I found for 2012-05-2


shared with delicious

Links for 2012-02-22

Some of the most interesting links I found for 2012-02-22


shared with delicious

Links for 2012-02-14

Some of the most interesting links I found for 2012-02-14


shared with delicious

Links for 2011-12-21

These are my shared links for 2011-12-21


shared with delicious

A few reasons to hate “flame wars”!

Flame Wars: The free post

I don’t really get those who treat brands like sports teams, offering blind allegiance over self-interest. That’s just zealotry. God bless that file system; my platform, right or wrong.

via If You Already Hate Windows 8 Then You Hate Technology [Gizmodo] .

 

Neither do I.

Throughout the years, I’ve been faced with flame wars in the various aspects of my life: programming language or platform of choice, operating system, camera gear brand, etc. . Fan boys that defend the lighter, faster, more stable or simply the best thing they’ve found as a crusade, feeding long hours and lengthy pages of discussions with empty arguments like someone keeps pouring gasoline to a bonfire.

I’ve seen too many Java programmers bashing vigorously .Net, programmers who don’t really grasp the main concepts of Object Oriented Programming. Console gamers that play the same game but keep repeating when it’s played in their . The endless Nikon vs. Canon feud, which is worth a post of it’s own, where in every meeting or photowalk people inevitably start counting how many Nikonians and Canonians are present, like choosing sides on a war. Some Apple fanboys, probably my favorite, that some time ago criticized Windows and praised openness of Linux and now seem to switched sides by defending a system that’s actually more closed than Windows.

I’ve chosen may brands but I never offered allegiance to any, some I’ve used for many years while I dropped others. I’ve always used Nikon gear, I’ve bought a grand total of four Nikon reflex cameras and a handful of Nikkor lenses, I was always pleased and never considered switching brands, despite finding features elsewhere that I love. On the other hand I used Windows for many years but got very tired of it, which pushed to try the several flavors of Linux, I ended up sticking with Ubuntu for it’s active community and the uncluttered, straightforward interface of Gnome, and the truth is feels more natural and fits me much better than Windows.

Regarding the post linked above, which caused me to write this rant, although my platforms of choice nowadays are Linux and Android I was really pleased with Windows Phone 7 (although I still believe it arrived too late and fail eventually) and I’m very curious to see how the Metro interface will evolve in Windows 8.

I guess that’s human nature that people like to choose sides.

Technology is just a tool, something to make your life easier and more comfortable. It isn’t a sports team or a religion to follow blindly, and since I’m openly “religionless” I’ll reserve my biased thoughts only to subjects related to my sports team.

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>

<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>();