I'm pretty sure the answer is no but just in case:
For a stand alone exe with an appropriate SxS manifest, is it possible to reference COM DLL's using a relative path or load them from a directory that is not the current directory?
We're operating in a grid environemnt that deploys various packages (i.e. zip files) using a common folder as the root. Several apps would like to reference a common COM Api (with DLL manifests) from a common location. However, as the grid environment is sandboxed we can't install to the Windows SxS directory and we also can't do it out of band (i.e. not deployed by the grid).
Do I have any hope of saying load COM.DLL from ..\SomeCommonDir\COM.dll or C:\Program Files\SomeCommonDir\COM.DLL ?
Everything works fine as a private assembly.
This should be possible using Activation Contexts. (I'm assuming that you OK with manifest etc as it sounds like you're able to get it working fine the 'standard' way...)
There's the 'hardcore' way of doing things here, or you can use the Microsoft.Windows.ActCtx object. These both allow you to manually / programmatically set the location of the client manifest for the Activation Context; the client manifest does have to be in the same folder as the assembly manifest and the assembly.
This SO question may be of use to you. And here's a snippet of one way to do it...
// Create an activation context
Type actCtxType = System.Type.GetTypeFromProgID("Microsoft.Windows.ActCtx");
dynamic actCtx = System.Activator.CreateInstance(actCtxType);
actCtx.Manifest = #"Path\To\COMClient.manifest";
// Create the object you want, using the activation context
dynamic obj = actCtx.CreateObject("COMTestService.COMTestObject");
// Now use it!
var question = obj.GetQuestionFromAnswer(42);
Related
I have "static" folder. This folder is used by express static. I created service (written in Go) which makes images smaller, so it can properly display on frontend. But when file is being moved to "static" folder it occures "The process cannot access the file because it is being used by another process" error.
(it worked great on linux, but on windows it shows me this error)
Let me know if any code is needed.
I solved this by not moving it with go script, using node (which is the process that uses static folder) instead.
I need to read the settings file (appsettings.json) from another project in my solution. When I use:
Directory.GetCurrentDirectory()
From within the current project, I get the following path:
{projectRootFolder}\bin\Debug\netcoreapp3.0\
My question is: How can I get to the exact same folder in another project in the same solution? Or is there a better way to access the settings file from another project within the current solution?
If I understand the problem correctly there are two misconceptions:
It has little sense to access output directory of an another project as the structure has sense in compile time only. You will not have the same structure in run-time once the application is "published".
The Directory.GetCurrentDirectory() returns the current working directory. It is just a coincidence to be set to project output directory by Visual Studio. It can be totally different directory.
It is not clear to me what exactly you are trying to achieve. I recommend using the configuration system provided by .net core to access the configuration and add that other appsettings.json as another configuration provider.
If you really need to open the settings file then the project with the settings file (A) should mark the file as "Copy to Output Directory" and the project to open the file (B) should reference the project A. So the settings file will be copied to output of the project A too.
What you're attempting to do is not possible. There's no inherent way for ASP.NET Core to know where a totally different app running in a totally different process is located.
If you need to access appsettings.json from another project, then you would need to include it as a linked file in your project, and set it to copy to output. Then, you're accessing it actually from your project (which is all you can do), but the file itself is shared.
However, this is almost always a bad idea, and usually a sign that you're doing something wrong. If you truly do need to share the settings, then what you should be doing is putting them in a distributed config provider like Azure Key Vault or similar, where both projects can independently access the settings from a common store.
I have been successfully using a Manifest string of:
file:///C:\Program Files (x86)\PathTo\MyAddin.vsto|vstolocal
in the registry. So it looks like this:
HKLM\SOFTWARE\..\Microsoft\Office\Word\Addins\MyAddin\#Manifest=file:///C:\Program Files (x86)\PathTo\MyAddin.vsto|vstolocal
It loads fine like this for me, and thousands of other people. Well, except on ONE machine in our shop - it won't load for him unless I remove the file:/// or reverse the whacks so they are file:\\\.
I have same .Net Framework 4.5.1 and VSTO Runtime 10.0.50903 as the person experiencing the issue. How could this be happening? Is there a correct URI format? Following this article it says to use /// (which I also believe to be proper for URI). Following this article it also says /// is correct
I have been developing VSTO add-ins for a long time and I always prefer to use Manifest without file/// or file\\\ prefix.
Simply use this
C:\Program Files (x86)\PathTo\MyAddin.vsto|vstolocal
OR
Use this in case you want to load Config file.
Covert the face of few slashes
file:///C:\Program Files (x86)\PathTo\MyAddin.vsto|vstolocal
To
file:///C:/Program Files (x86)/PathTo/MyAddin.vsto|vstolocal
just wondering if it's possible to include some files (one txt file in this case) in the app package that I need in the application folder. The thing is that I might use a piece of code that requires the license to be included in the app as a text file, and I think this would be one way to do it.
Thanks in advance.
Absolutely, it's really no different than including images for instance. And if you need to process the file within your app you can access it via its local path or explicitly use the ms-appx:/// protocol.
See How to reference content and How to load file resources for more details.
Just include the file in your project with Build Action set to Content. You can put it in any folder you like.
The file can then be accessed from the app either using the ms-appx: protocol or using the StorageFolder API:
var license = await Package.Current.InstalledLocation.GetFileAsync("license.txt");
I'm doing a proof of concept app in SL4 using MEF and as part of the app I am importing another xap from an existing Silverlight Project and displaying it in my host project.
The problem is that the existing app uses some .xml files (as content) and it uses linq2xml to load these files which are (assumed to be) bundled in the xap.
When I compose the application the initalization fails because the host app doesn't contain the xml files. If I copy these xml files into the host project and run it the composition works fine. However, I need to keep the xml files in the original project.
Is there a way that I can download a xap and look at it's contents for xml files and then load them into the host xap at runtime so that after the compostion takes place the xml resources that are required can be found?
Or should I work out some kind of contract with an import/export to pass the xml files to the host xap?
As the people developing the imported xaps (should the project go ahead) are from a different company, I would like to keep changes to the way they develop their apps to a minimum.
I assume you are using the DeploymentCatalog to download the second xap? Unfortunately there's no way to get at resources included in that xap. You could have the resources embedded in assemblies which are included in the xap, and then modify the way they are loaded.
If you really don't want to change the way the secondary xap is structured, you might be able to write your own DeploymentCatalog which would also allow you to load resources from the downloaded xap. The source code to DeploymentCatalog is available, so you could base it off of that.
I've managed to find a solution that I'm fairly happy with.
Instead of building the .xml files as 'content' to go within the xap, I have built them as 'resource' then used Application.ResourceStream() and loaded the xml using a stream.
It means the second xap developers will have to change the way they operate, but its only one extra line of code and changing the Build Action, I'm sure they can handle.