The Metro documentation states that the applications are self-consistent (no shared DLL’s, etc), So I’m just wondering how you can create a modular, BIG Metro application by creating reusable ponents/libraries.

Considering the case for HTML5/JavaScript Metro apps, if a lot of them should contain the same CSS and JavaScript (consider jQuery, templates) or WinJS scripts then it doesn't look quite good … I expected some form of libraries/reuse to exist from the start.

The HDD space is definitely cheap nowadays but I think that a versioned library repository should be in place and the dependencies (WinRT ponents/libraries, JavaScript libraries...etc) should be loaded on demand (if not already available). No "wheel invention" here needed, just look how Maven and Ivy is doing it .... otherwise will find out that our beloved jQuery 1.6.4 library is deployed in tens (if not hundreds) of applications and the bloat is ready ...

The Metro documentation states that the applications are self-consistent (no shared DLL’s, etc), So I’m just wondering how you can create a modular, BIG Metro application by creating reusable ponents/libraries.

Considering the case for HTML5/JavaScript Metro apps, if a lot of them should contain the same CSS and JavaScript (consider jQuery, templates) or WinJS scripts then it doesn't look quite good … I expected some form of libraries/reuse to exist from the start.

The HDD space is definitely cheap nowadays but I think that a versioned library repository should be in place and the dependencies (WinRT ponents/libraries, JavaScript libraries...etc) should be loaded on demand (if not already available). No "wheel invention" here needed, just look how Maven and Ivy is doing it .... otherwise will find out that our beloved jQuery 1.6.4 library is deployed in tens (if not hundreds) of applications and the bloat is ready ...

• javascript
• html
• windows-8
• microsoft-metro
• windows-runtime

• 1 A downside of this sort of "isolated assembly" idea is what they call servicing. Say you have 60 apps that all use your WackyWidget library, and oops you find a bug. Sounds like you must redeploy all 60 apps to all users instead of pushing out a patch to correct the single shared DLL you'd have had in the past. – Bob77 Commented Sep 16, 2011 at 12:58
• @Bob On the other hand, it may be somewhat confusing to the user when you only update the DLL. When you update an app, they see it in the list of apps to update, look at the changelog, confirm/refuse it and so on. When you update a DLL, how do you explain it to the user? It's not an app. It's something that will affect other apps. The changelog would only make sense to a programmer, not to a user. – Pavel Minaev Commented Sep 16, 2011 at 15:48
• Well when patches are pushed via Windows Update, SUS/WSUS, etc. there is no list of applications provided to the user. In the case of some libraries it could be a LOT of applications. We have the same issues here with internal applications that use quite a few widely-shared libraries among them, and seldom push out whole new install packages. This makes sense to admins more than either programmers or users I suspect though. – Bob77 Commented Sep 17, 2011 at 2:25
• The fact that they won't allow shared libraries is a really bad sign for anyone that's into ponent design. From a developers point of view I can't see any benefit in disallowing shared libraries. – MFH Commented Sep 17, 2011 at 3:59

4 Answers 4

As a general rule, each WinRT/Metro style application can access only dlls that are built into Windows or are shipped in their appx package. There is no facility to ship centrally referenced dlls. Each application that wants to use a dll/library will need a copy that ships with it.

You can share libraries, you just won't be doing it using DLLs. You can easily create a class library with mon utilities and functions, then reference/share it in your application. You can also drop to C++ and create your own shared functions via WinRT.

As you point out there isn't any kind of Global Assembly Cache for saving a single instance of a library/ponent and sharing it with any app that needs it. While the GAC in .NET is nice, I don't think very many developers take advantage of it. Hoe many one off .NET apps share ponent assemblies that are saved in the GAC? I believe the percentage isn't very high, consequentially all those assemblies are duplicated. The decision to not spend time on a Metro GAC seems warranted to me.

They would need to implement 3 global caches for Metro if they did build it. One for each .NET, C++ and JavaScript. It seems to make sense. This just sounds like a mess. Plus, how does the cache know that no apps on the machine use a certain assembly anymore and it can be deleted? Messy...

This is a fairly plex topic, and doesn't really have a short answer solution. No matter the debate, they may be working on a solution to this and just haven't released it in the Windows Developer Preview. More time is needed to see how the platform evolves closer to release.

WinRT allows a Metro application to take a 'dependency' on a Framework object. That object can contain all the shared DLLs, etc. that multiple applications may use.