Tag: framework

  • .NET v4.0 building missing targets

    C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(847,9): warning MSB3644: The reference assemblies
     for framework “.NETFramework,Version=v4.0” were not found.

    If you end up building .NET projects outside of Visual Studio, just using the .NET v.40 runtime, you may (will?) hit the above warning, but who likes warnings from systems, anyways? You have the option of either installing Visual Studio, but then what’s the point if you had to ship build files in the first place. This is not an option on production systems, and needs resolution.

    It seems, the full framework alone doesn’t install the correct target libraries when using a non-VS build environment (MSBuild.exe). I was lucky to find in a forum about a working fix, and it works like a charm.

    1. Download and save the  Windows SDK v7.1 32-bit x86 ISO image from Microsoft.

    2. Copy the ISO image to the server using the local network

    3. Download Virtual CD-ROM Control Panel v2.0.1.1 from Microsoft

    4. Unzip Virtual CD-ROM Control Panel and follow readme.txt instructions to install and mount the ISO image.

    5. Uncheck everything except .NET Development > Intellisense and Reference Assemblies in the installer.

    6. Finsh the install.

    If you now try to build, no more warnings are generated, and you’re good to go.

  • Spring and Logback

    IoC, or DI definitely takes a perspective turnaround inside your head, but you get around it slowly.  I was playing around ways to integrate LogBack, and Spring – essentially around having Spring give me a pre-created instance of LogBack logger.

    I searched around posts, but most people seem to be against using Spring just for substituting one-line of Logback (Logger log = LoggerFactory.getLogger("LogbackTest");) to get your logger.

    I, on the other hand, was more interested in how to get Spring give me a LogBack logger instance without too much contrived hand-written code to achieve so. And with a bit of reading through Spring principles, documentation I found the way.

    Essentially, when using Logback’s LoggerFactory you have access to only a single getLogger() factory method. This is static which makes things a bit different for what Spring would call a bean – a class providing constructor, getter, setter methods. To circumvent this non-bean style, Spring provides what you call as static initializers a.k.a substitutes for constructors, which allow you to call a static method in lieu of calling a constructor on an object.

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
     "http://www.springframework.org/dtd/spring-beans.dtd">
    
    <beans>
     <bean id="bean1" class="org.slf4j.LoggerFactory" factory-method="getLogger">
     <constructor-arg value="LogbackTest" />
     </bean>
    </beans>

    Now, this bean1 can be used as a regular bean inside your class

    ApplicationContext ctx = new FileSystemXmlApplicationContext("logbacktest.xml");
     Logger log = (Logger) ctx.getBean("bean1");
    
     log.debug("This is my first message");
     log.info("How about this information message");

    Throw in a logback.xml in your classpath, and viola you have a nice Spring injected dependency – log in your code, while still using Logback!

  • Spring IoC, DI quick tutorial

    There has been an (evident) craze amongst Java community with contrived terms such as IoC (Inversion of Control), DI (Dependency Injection) mainly through Spring. I initially found the connotation “Don’t call me, I’ll call you” a bit difficult (yeah, it’s bending your head upside down) to understand, but after spending few hours around Spring documentation, I get the gist.

    To a layman (Java layman, of course) it is helpful to picture that each Java program is a set of one or more classes, which act together. Essentially, this means classes are “dependent” on some classes in order to be fully functional. Usually, the class requiring functionality of another class instantiates the class, and uses it. This is called coupling because class instantiates the object of required class. What if we always got an “instantiated” instance of required class, and our class did not have to worry of instantiation? – This is called IoC (Inversion of Control) principle in Spring, and it achieves this by providing ready-to-use instance (injecting dependency) to your class. This has some important uses, since now you don’t worry of creating connections to databases, loggers to log4j, or sessions for JMS queues. Spring will create these for you, and your class can focus on the actual purpose – using the pre-instantiated ready-to-use object.

    Get it? OK, to simplify it further, let us assume you have a class A having one field – log. You want to use log to log information, but your class nowhere has the logic to instantiate or initialize log. You accept a pre-instantiated log through constructor, or getter/setter methods, and you will have a ready-to-use log instance passed to your class via Spring!

    I won’t go into details of Spring further, since Spring’s own documentation on http://static.springsource.org/spring/docs/2.5.x/reference/index.html is the definitive source to look into.

  • Create toolbars in .NET C#

    I have created a framework in .NET C# to allow creation of toolbars with extreme ease.

    http://azibo.sourceforge.net/

    Definitely have a look at the website for details, and examples!