Tag Archives: .net

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

Links for 2010-06-29 through 2010-07-16

These are my shared links for 2010-06-29 through 2010-07-16:

Links for 2010-02-5

These are my shared links for 2010-02-5

Two .NET 4.0 lesser-known features [Just another Software Engineer]

Improved Unit Testing and built-in Caching (outside the System.Web assemblies)
shared in delicious, tags:.net programming shared


35 Google open-source projects that you probably don’t know [0x1fff]

shared in delicious, tags:google software opensource shared


What’s New in ASP.NET MVC 2.0? [CodeGuru]

shared in delicious, tags:.net aspnetmvc programming internet shared

Spam really gets everywhere, even dotnetkicks

dotnetkicks

Spam really gets everywhere, the screenshot on the right is from the Tags box in the front page of DotNetKicks, a Digg-like online community dedicated to .Net programmers.

 

 

 

 

 

Technorati Tags: ,

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: 

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

Switch to our mobile site