So far it's unclear what you're actually trying to do. WRL is just a C++ helper library for WinRT, if you're using C++ (think of it as WRL-is-to-WinRT-as-ATL-is-to-COM).
Let's take C++, since that's the 'most raw' and has no vm or runtime like C# or JS. You're trying to instantiate a WinRT object that you didn't link with? If so, that's simple - ActivateInstance(activateableclassid). The real question is what are you trying to instantiate? If it's a 1st party (inbox/Windows) component, it should just work. This is very much like COM, where there ACID is like a CLSID and ActivateInstance() is like CoCreateInstance().
If you're trying to instantiate a 3rd party WinRT component (not shipped w/Windows), it's a little simpler. The ONLY way to register 3rd party WinRT components is by including them in your package. Packages are isolated from each other, so you cannot have, e.g. AngryBirds deliver a FOO WinRT object and use it in an app in the Scrabble package. Unlike COM where registration is machine wide (or in the rare even you register under HKCU instead of HKLM, user-wide), WinRT 3rd party (package'd) WinRT objects are only registered for use by apps in that package.(1)
(1) That's a little white lie. Technically your application can instantiate WinRT components provided with Windows and WinRT components provided by packages in your package graph. You can make a Framework package which includes WinRT objects, and have your application's package dependent on that. Windows figures our your package depends on the framework and thus your 'package graph' has 2 packages in it -- your app's package and the framework package. BUT you cannot submit Framework packages to the Store. Local development and enterprise/side-loading deployments can do this (they don't go through the Store and thus don't need to meet Store submission criteria), but any application package submitted to the Store can only depend on the Windows provided frameworks (WinJS, VCLibs, PlayReady/DRM). That's how PlayReady works - it's a Framework package containing (among other things) some WinRT objects; if your application's package declares a on it your package graph will contain 2 packages (your app's package + playready's package), and ActivateInstance() can resolve ACIDs across the union of packages in your package graph.
There's a lot of protections built into the application model. This is one of them. This prevents 'COM Hell' and 'DLL Hell' - everything's fine, then 6 months later you install app Y and for no apparent reason app X no longer works. The new appmodel is designed to prevent that scenario.
Another protection is the limitation of where package'd WinRT objects can be found. Even if you put a file in your app's local folder (e.g. ApplicationData.current.localFolder), ActivateInstance() won't find it. WinRT doesn't look under AppData (or oodles of other places) for registered WinRT objects -- only those in your package graph (and 1st party (Windows) components provided with the OS, e.g. StorageFolder).
provide the GUID of the CoClass of the COM, the using program knows
only about the interface and CoCreateInstance will dynamically load
the COM and create an instance attached to the interface you're
requesting.
The WinRT equivalent is to provide the ACID of the runtimeclass of the WinRT [component], the using program knows only about the interface and ActivateInstance() will dynamically load the WinRT [component] and create an instance attached to the interface you're requesting.
The caveat is, the WinRT component's implementation must be registered in your package graph, i.e. must be listed in your app's package's AppXManifest.xml, or a dependency's AppXManifest.xml.
That's at the most raw level, if you deal directly with WinRT at the ABI level. C++ projections are equivalent, just more convenient syntax. The CLR and JS runtimes provide their own additions and variations of enforcement (e.g. search for "windows 8 javascript local vs web compartment") but they just further color the behavior. They can't overrule the underlying OS' baseline behavior.
As Damir noted
You won't be able to put new files to install folder any other way and
that's the only location from which executable code can be loaded by
the app.
"Executable code" comes in varying forms, depending on your definition.
WinRT components can be loaded from other places (Windows provided WinRT components, dependent packages e.g. the PlayReady framework package).
(Non-WinRT, non-COM) 'native' DLLs can be loaded from other places (executable's directory, System32, etc). See Search Order for Windows store apps.
.NET assemblies in DLLs have their own similar restrictions e.g. Assembly.Load().
Some people consider Javascript "code", and there's the whole local vs web compartment thing to further color where code can be resolved from.
As a general rule, you can dynamically load code in a variety of ways, but it needs to be known code. There's no supported way you can create e.g. a C++ app that will load DLLs (WinRT or non-WinRT) that's not known at Store submission time. You can write an app using optional (conditionally loaded) code, you can have 'plugins' -- but they need to be in your package when you submit to the Store.
You can't build e.g. Outlook as is today, where Outlook is submitted to the Store with an open-ended plugin model and sometime later install an OutlookNiftyCalendar add-on which Outlook could find and use. Not in Windows 8.
(there are some ways you can bend this rule a bit in a Javascript app via web compartment, but that's a complex topic in its own right, and even that has limits both hard and soft/policy. And irrelevant if you're not writing a Javascript applications)
