Errr, some catchy title.... RSS 2.0
 Tuesday, January 22, 2008

This post is a more of a reminder for myself as I have to do this every few months and I end up googleing it every time, because I don't remember what exactly needs to be done.


The problem:

How to get your hands on the DLL (as a file) that is stored in GAC.


The solution:

When you go to Windows\assembly directory you will see something like the screen below.





The above Shel extenstion is great for quickly checking which versions of GACed DLLs are installed on the machine.

The problem arises when you want to copy the DLL itself (as a file). In this shell extension (Assembly Cache Viewer (SHFusion.dll) you're not allowed to do that. You may wonder why would you want to copy those DLLs in the first place. Well, for example when you want to install the DLL on the machine and the only copy of the DLL you've got is in GAC.


Ok, enough foreplay. Here's the actual solution:


For first time on each machine add key:

DisableCacheViewer in

HKLM\Software\Microsoft\Fusion

Set the DWORD value to 1.


Now if you go to the assembly directory you'll see the following screen.





For all future usage, simply toggle the registry value.


NOTE: There are other ways of doing this, such as disabling SHFusion via command line, but I find this one the easiest.


Tuesday, January 22, 2008 4:55:34 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other | Tools
 Wednesday, January 09, 2008

I've updated the blog engine. I have moved from ThinkJot to dasBlog version 2.0.

The move has been really easy. I've simply copied all the new files to the directory. Moved the files from the old 'content' directory to the new directory and that's it!

Oh yeah, I've also edit some configuration files.

Now that's a true XCopy experience!

While updating the blog I've decided to use a new theme. I've moved from essence to business (I've modified it slightly...). I hope everyone likes it.

I really like the new engine, it's got a few fixes that I was waiting for...

Wednesday, January 09, 2008 11:38:24 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other
 Wednesday, November 21, 2007

Disclaimer: Nobody paid me for this post. I am not endorsed by anyone in any way. Although, I do accept donations :D.

 

 

I’ve been using tools from xSQL for a few months now. I have to say, I love those guys.

 

There are the three products I use the most.

 

xSQL Data Compare, which is a typical application for synchronizing data between databases. The cool part is that they have a free edition for smaller databases. It’s great when you’re just starting a project and there not many tables, sps… and yet, you still have to continuously keep data synchronized between versions.

 

The other tool that I absolutely adore is xSQL Script Executor. All it does is runs numerous SQL scripts as batch. If you use VSS for storing all your tables, sps and relationship scripts you will really appreciate this tool. Thanks to it you can rebuild whole database in a matter of seconds. Furthermore, I believe this is the only tool like that on the market (meaning, google didn’t find anything that was even similar J ).

 

Finally, a truly innovative approach to working with DBs: xSQL Object Search. It allows you to search for objects (tables, sps and such) based on their name. This tool is invaluable when you get an existing project that uses behemoth of a database, and you have to locate some related objects (say, you want to fix some functionality of the system).

 

On the final note, did I mention that xSQL Script Executor and xSQL Object Search are totally free!!!

Wednesday, November 21, 2007 1:57:18 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Tools
 Friday, November 09, 2007

This is a quick tip. Below is the code that you can use when you want to find what's the name of the Virtual Directory.

string virtualDirectory =AppDomain.CurrentDomain.FriendlyName;

virtualDirectory = virtualDirectory.Substring(virtualDirectory.LastIndexOf("/"));

virtualDirectory = virtualDirectory.Substring(0, virtualDirectory.IndexOf("-"));

 

Notes: This has been tested in IIS 6. If you run this code in ASP.NET Dev Server you'll get an exception as CurrentDomain.FrienlyName will not contain any '/' (no virtual directory).

Friday, November 09, 2007 2:35:53 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
ASP.NET
 Wednesday, September 26, 2007

Here’s the list of thing you have to do in order to connect to Microsoft SQL Server (tested on 2005) with integrated connection (without any usernames passwords).

 

  1. Assuming you have installed Ruby on Rails. Go to Ruby\DBI and get the latest release of ruby-dbi package.
  2. Extract the package to some temporary folder and find file in directory: \lib\dbd\ADO.rb.
  3. Go to location of Rails installation (C:\Ruby by default) and traverse the directory path to: lib\ruby\site_ruby\1.8\DBD\
  4. Create a directory ADO
  5. Copy file ADO.rb (from the extracted package) to the newly created ADO directory.

 

 

This configuration will work for all you Rails applications.

In order to set up a proper connection to your database from your application edit config/database.yml file.

 

Here’s the example of what you should input if you use Windows Authentication.

 

adapter: sqlserver

database: Marcin

username:

password:

host: DBI:ADO:Provider=SQLOLEDB;Data Source=servername,port;Initial Catalog=databasename;Integrated Security=SSPI;Network=networkname_if_necessary;

 

Notice, that since we’re using Integrated Security we’re not leaving username and password blank. This greatly reduces the maintenance of this configuration file.

Wednesday, September 26, 2007 3:17:42 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Ruby
 Tuesday, September 18, 2007

If you’re a Vista laptop owner you definitely want this application installed on your machine.

It’s a Vista Battery Saver !

 

 

 

 

What it does, is when you switch from A/C to batter it will disable Sidebar and Aero (all of this is of course configurable). I can squeeze out over 40 minutes more of battery time with this little application. Also, this is and open source project written in C#. Here’s the code. It’s a very interesting read.

Hope it helps.

Tuesday, September 18, 2007 12:34:30 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other | Tools
 Wednesday, August 29, 2007

Below are two quick tips for testing non public classes and methods. I am not saying that it is a best practice to test your non public methods (usually indicates that there is something wrong with the design), but sometimes you just have to do it :).


Testing internal classes:



  1. Right click your test assembly.

 

2.Select a file

3.Instead of clicking Add, select 'Add as Link'.

 



Next, comes up testing non public methods:


The code below uses MbUnit testing framework (much better then NUnit). MbUnit has a class called Reflector which allows you to test non public fields, properties and methods. The only problem with this is the same one I have with many of the mocking frameworks: all of the names of properties and methods must be passed as strings, therefore there is no compile time validation. But hey, you can't have everything. :)


internal class ItemProcessor

{

      public ItemProcessor (List<ItemAttributeRiskFactor> attributeRiskFactors)

      {....}

.......

.......


      private bool CheckIfItemAttributeRiskFactorCorrespondsToItemAttibute(ItemAttributeRiskFactor risk,

                                                                                                                        ItemAttribute attribute)

      {

            if (risk.AttributeId == attribute.Id &&

               risk.AttributeValue == attribute.AttributeValue)

                     return true;

            return false;

      }

  }


The above code, is from one of my pet projects so you must forgive me that you don't understand what the class does. The important thing is that the class has private method that I want to test.

Below is the test code.



using MbUnit.Framework;

using MbUnit.Framework.Reflection;


[TestFixture]

class ItemProcessorFixture

{

   private Reflector reflector;

   private ItemAttribute attribute;

   private ItemAttributeRiskFactor risk;


   [TestFixtureSetUp]

   public void FixtureSetup()

   {

         ItemProcessor processor = new ItemProcessor(new List<ItemAttributeRiskFactor>());

         reflector = new Reflector(processor);

   }


   [SetUp]

   public void TestSetup()

   {

         attribute = new ItemAttribute();

         risk = new ItemAttributeRiskFactor(4, "HIGH", 50, false);

   }


   [Test]

   public void ItemAttributeAndItemAttributeRiskFactorShouldCorrespond()

   {

         attribute.Id = 4;

         attribute.AttributeValue = "HIGH";


         Assert.IsTrue((bool)reflector.InvokeMethod(

                     "CheckIfItemAttributeRiskFactorCorrespondsToItemAttibute", risk, attribute));

      }

   }


The interesting part of the code are in bold. We use MbUnit's Reflector class to test private method of the ItemProcessor class. Furthermore, the Reflector allows us to set and get fields and properties.

Overall, while it isn't a perfect way to test non public methods, it sure is better then not testing them at all :).

Wednesday, August 29, 2007 3:42:36 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Testing | TDD
 Thursday, August 09, 2007

Developing an application that supports plugins is not an easy feat. Below are some links that will help you start the ball rolling:


One from CodeProject. Next one is from Roy Osherove on MSDN. Actually, it has two parts. Part one and two. After reading those you will have general idea what you should do. How to start, how to look for appropriate plugins and so forth. I would like to point out a few things more you should take into consideration.


First of all, what will the communication between the application and other plugins look like. How and if the plugins send any information to the hosting application. This of course depends on your applications requirements.


Another big one after communication is how will you visually present the plugins. If they are to be presented in the UI (added to be MainMenu or ContextMenus) the framework must allow it. Also remember not to pass references to your menus, because plugins would be able to delete some entries there. Rather allow a plugin to specify location and items that should be added to menus. This will be safer. (When returning those objects the plugin should already have attached the required event handlers).


Exception handling is also very important. How will you act when your plugin will throw an unhandled exception? Will the whole application crash or will it report gracefully that there was a problem with a certain plugin? For WinForms development there are two events you should register to: Application.ThreadException

AppDomain.UnhandledException.



On the final note, there is dnrTV Show on plugins in .NET. Be sure to watch it.

Thursday, August 09, 2007 2:32:09 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other
 Monday, July 09, 2007

Here is an essay I wrote for my Masters course. I think it could be an interesting read...

 

"Comparison between DTD and XML Schemas"

 

Introduction

Document Type Definition (DTD) and XML Schema are XML schema languages, therefore both of them are used to express a set of rules to which an XML document must conform in order to pass validation. We need schema languages in order to check whether a given document conforms to all the rules given business must enforce.

DTD is native to XML schema language. It has been around for a long time; however it has some shortcomings which will be discussed later.

XML Schema has been developed later with the same purpose as DTD in mind; however it tries to negate DTD’s shortcomings. Furthermore, XML Schema is the first schema language that has been recommended by W3C (World Wide Web Consortium). An instance of XML Schema is called XML Schema Definition (XSD). As, XSD has been designed later it isn’t as limited in functionality as DTD.

DTD versus XML Schema

DTD lacks a couple of important constructs that are vital to working with XML documents. The biggest concern is that DTD syntax is based on SGML not the XML itself. Therefore from the technological standpoint, there is a need for two parsers. First one to validate XML file (just for structure integrity, not for conforming to set rules) and the second one to validate DTD file (again, just the structure). XSD is simply an XML file; therefore we can validate structural integrity of the XSD and the target XML document with just one parser.

As DTD was designed to be a schema language it is very troublesome, that it lacks a very important feature. It lacks data typing. It is impossible to specify what should be the type of the given element. For example it is impossible to enforce a rule that the amount of transaction is of type double. One could still pass a string and DTD parser would state that the XML document is valid. In XSD, one is actually forced (it is a required attribute) to specify the type of an object for each element; hence this problem has been completely mitigated in XSD. XSD also has type called ‘anyType’ for those special situations when type is not important, or it differs for different documents.

Another important shortcoming of DTD is the fact that it is impossible to specify the number of occurrences of a given element. Therefore, a lot of the validation must still be done even after the parser says that the given document conforms to the DTD schema. XSD on the other hand has properties: ‘minoccurs’ and ‘maxoccurs’ which obviously are not perfect but are definitely a step in the right direction. Of course, there are situations where these properties will not be sufficient to specify the business rules required and again the work lies on the shoulders of the developer that must check whether the file corresponds to the standards.

Since the creation of DTD, XML has evolved, newer constructs have been created. Unfortunately, DTD has not been up to par with those. An important feature of XML files are namespaces. They have been created due to the fact the XML has become a mainstream standard and therefore the documents have started to grow very large. It is not uncommon for a document to use two different set of vocabularies. If those vocabularies have the elements with the same name then it would lead to unmanageable files. Creation of XML namespaces has solved those problems. Unfortunately, there is no support for XML namespaces in DTD. This is a big limitation in most modern systems they are simply a must. On the other hand when creating an XSD file, one must specify the namespace of the specification. This and the fact that since XSD is an XML file and has its own namespace shows that this feature of XML documents is deeply supported.

Corollary

DTD is an old technology (it is based in SGML which was developed in 1960s). XML Schema came into being when XML became very popular and it became clear that DTD cannot meet the needs of the businesses. XSD was developed with all the shortcomings of DTD in mind. It was supposed to mitigate all the problems that DTD has. It is believed that the XML Schema is the successor of Document Type Definition.

To sum up, there are a lot differences between the two technologies, even though they attempt to solve the same problem. It is important to note, that even though XML Schema seems far more superior it is simply because it was developed much later then DTD. Most legacy systems still use DTD, however new systems tend to lean toward the usage of XML Schema. To ease in this transition there are a lot tools that allow translating DTD files into XSD format.

Monday, July 09, 2007 7:01:17 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Other
 Thursday, June 28, 2007

So, you wrote your first RIA and you want to publish in on the web and start counting those millions of dollars coming in. You deploy your application, type in the link but, nothing happens. Why?

 

 

 

It could be, that your hosting service doesn’t support .xaml files (mine started around a month age). There is a quick workaround for that, simply rename your .xaml files to .xml. You have to update your references accordingly, such as when you create your xaml object via JavaScript. Luckily, if you do that, everything still works (Intellisense) inside Visual Studio so if you do this before deployment, you won’t have any problems.

 

Note: You don’t have to do this for User Controls as they are compiled into the binary file.

 

Let’s assume that you have created your Silverlight project that consists of one Page.xaml file some User Controls, one Default.html page (so typical set up in Visual Studio). Below is a list of files that need to be uploaded to the server:

 

Default.html

Default.html.js

Page.xaml (or Page.xml)

Silverlight.js

 

And the most important one:

ClientBin (the directory in which is the client DLL)

Thursday, June 28, 2007 10:16:01 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
Silverlight
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Marcin Waligora
Sign In
All Content © 2008, Marcin Waligora
DasBlog theme 'Business' created by Christoph De Baene (delarou)