If you're stuck with using a library supplied by someone else, and if attempts to lobby them to produce a portable version are unlikely to succeed, then about the only thing you can do is find somewhere else to host the DLL, and then communicate with whatever is hosting it. For example, for some scenarios it may be possible to write, say, an ASP.NET Web API based service, which will be able to use the full .NET Framework and will thus be able to use the DLL.
Obviously, this trades one problem for another: you now need to have a machine which can run a web service for you. (And unfortunately, I believe Microsoft does not officially support running that web app on the same machine that's running the Windows Store app. You may be able to get it to work on your dev box, but you'll not be able to deploy the web app itself via the Windows Store.)
And there's no easy path here - you'll have to write a layer exposing everything you need via HTTP services, and client-side code to consume those services. And you'll also need to think about how to to secure access to the service.
It may be easier to plead with your supplier...
In theory, if it so happens that the library isn't using anything outside of the core .NET profile, then you could use ILDASM and ILASM to de-compile and re-compile the code, converting it to a portable library before doing so. However, this is quite likely to breach your license agreement if it's commercial code, and in any case, is quite likely not to work.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…