Strong naming an assembly without having the actual source code

Today I had a blocking issue, I was in the process of Strong naming my assemblies yet I was referencing a third party assembly that was not strongly named. This cause a compilation error :S what to do????

A colleague David Field sent me 2 command line snippets that do just the thing…

Basically the idea is to use ILDASM.exe (which comes with .net SDK) to convert the dll to il and then use ILASM to make that IL badk into a dll and sign it. (please note you need an SNK file, you can create one easily with the sn.exe or just use one from the other assemblies you are signing)

the magic of ILDASM and ILASM >>

ildasm myassembly.dll /out:myassembly.il

where myassembly is the name of the DLL

and then we convert that IL back in a dll and sign it with ILASM

ilasm myassembly.il /dll /key=MyStringNameFile.snk

Hope you find this useful I sure did

Infusion Malta is looking for talents

 

 

I’ve been working for Infusion for over a year now and I must say, even though I complain a lot (yea I am one of those guys that complains and complains and complains), its truly an amazing place to work! You get to work on cool cutting edge technology projects and to top it off you get to work with awesome people (probably bigger Geeks than you!).

I love the fact that Infusion is open to new ideas, case in point “Infusion Malta”; I was talking to Managing Director of Infusion London and told him “what if we open an Infusion Malta?”, and here we are today 🙂
*P.S Malta is where I was born… more info on Malta can be found be goggling it 😛

So back to the original subject 😛 We are looking into building a small but efficient team in Malta, I call it Infusion SWAT team 🙂 We are looking for both developers and designers…

For Developers >>
1. You must be a Geek
2. Good C# skills
3. open to work on new technologies like Win Mob7 and Surface
3. Want to learn/work on WPF and Silverlight.
4. Willing to work with me 😛

For Designers >>
1. Good in Visual and Interactive design.
2. Want to learn/work on Expression Blend
3. Willing to work with those other strange people… yea I think they call them developers..

Hope I got you all excited and that you’ll send your CV to me at mgrech@infusion.com 🙂

see you in Malta 🙂

Adding more goodies in MEFedMVVM

Thanks to some good feedback from the community and also some really awesome help from Glenn Block and Sasha Barber, I added some new stuff to MEFedMVVM.

The core 3 additions are

– Reloading of design time data in Blend as you compile in Visual Studio (Patch by Chris Szabo)

      Before this patch you had to close and re open Blend everytime you did a change in your ViewModel for Blend to pick up this change. Chris Szabo sent me a code snippet showing me how I could overcome this issue. Very cool Chris!!!!!

– Added a new method in IComposer so that you can specify a list of custom ExportProviders.

      A user of Cinch suggested this feature since he had some ExportProvider he wanted to use in MEFedMVVM for versioning of objects. Now the IComposer has a new method that looks like this

You can return a list of ExportProviders or if you do not want to just return null. MEFedMVVM will attach its own ExportProvider even if you return null. (MEFedMVVM uses the ExportProvider for IContextAware services such as IVisualStateManager so that it can inject the View that requested the ViewModel)

–

– Added 2 new attached properties to make things more clear.

By default Exports in MEF are treated as Shared. This implies that if before you did an [ExportViewModel(“MyVM”] without specifying a [PartCreationPolicy(CreationPolicy.NonShared)] the ViewModel would be exported as a shared item so all imports get the same instance of the ViewModel. Also this implies that the ViewModel would never be garbage collected since MEF will keep its instance alive. The workaround for this would be to specify [PartCreationPolicy(CreationPolicy.NonShared)] where you put the ExportViewModel attribute. Once you know this its all good but if you are new to MEF maybe it is not that obvious that exports are by default Shared. So in order to make this crystal clear I added 2 new attached properties SharedViewModel and NonSharedViewModel, which will impose the CreationPolicy on the ViewModel you want to export (this is like doing the CreationPolicy on the Import if you were doing standard MEF). Glenn Block came up with this idea, kudos to Glenn!!!!

 

Besides these changes I also did some bug fixing here and there and some minor changes as per request …

– Export for ViewModel had an incorrect ImportCardinality. now the ImportCardinality is set to ExactlyOne.
– DataContextAware ViewModels used to call the DesignTimeInitialization 2 times, this is now fixed.
– Exposed the MEFedMVVM CompositionContainer, you can now access the CompositionContainer directly by doing this ViewModelRepoitory.Instance.Resolver.Container. This is useful if you want to get some Exported object from the CompositionContainer that MEFedMVVM is using.
– Fixed issue with ImportMany. This was a problem in the ExportProvider of MEFedMVVM.
– Added propertyObserver. you can see more about this here
– Fixed issue with DelegateCommand (was not hocking automatically to the CanExecute of the Command Manager in WPF)

Hope you enjoy MEFedMVVM and as always keep feedback coming !