I have a software diagnostic page on which I would like to list the File Version information of a couple of COM DLLs. The page is running under the normal, restricted ASP.Net account (NETWORK SERVICE).
Given the ProgIDs of a COM library, what's the best way to go about getting the physical file path or otherwise accessing the file version #?
Note that loading it via Type.GetTypeFromProgID and using the type's Assembly object won't work, as the Assembly object returned is the one for mscorlib.
The install path can be selected by the user and is not guaranteed to be a specific value.
One way of approaching this is to use the COM function CLSIDFromProgID (Pinvoke.Net shows how to call this from .Net here) to obtain a CLSID, use the GUID.ToString("B") to convert the CLSID to a suitably formatted string then use it to go grovelling in the registry to find where the COM server is registered.
The path will be
HKEY_CLASSES_ROOT\CLSID\<YourCLSID>\InprocServer32 if the COM server is an in-process server (i.e. a DLL as you're expecting)
Note that the file path in the registry is not necessarily a fully qualified path.
Related
I am having some trouble with BizTalk saying a schema doesn't exist when it does exist.
I can see it in the BizTalkMgmtDb using
select * from bt_documentspec where msgtype like '%myschema%'
I can see it in the BizTalk Server Administration Console > <All Artifacts> > Schemas > My Schema.
This paragraph is optional. I'm only including it so you know I already tried the answer you get when you google this problem.
The exact error message I get is something like "This Assembler cannot retrieve a document specification using this type" which if you google that tells you the schema is either not deployed or the root element you're using exists in two separate namespaces so you should supply a DocSpecName on the SendPorts XMLTransmit 1 2.
I've also tried reinstalling the dll that contains the problem schema into the GAC as per the answer to this question. That didn't work either but now I have more questions anyways.
if I do gacutil -l none of my assemblies are listed there.
So I was wondering what does this even do?
Because those assemblies are not listed under gacutil -l. Also when you look at those assemblies
it shows a source location and a destination location.
Why? Why not just THE location? I can't even find %BTAD_InstallDir% on my computer so there are a minimum of 4 possible locations where this schema dll might be.
source location
destination location (%BTAD_InstallDir%)
"the GAC"
wherever it actually is because there doesn't seem to be a %BTAD_InstallDir%.
So if I want to "update the GAC" to make sure this schema is there how do I do that? What dll is BizTalk ACTUALLY using? The one in %BTAD_InstallDir% or the one in the GAC?
BizTalk 2010.
It has nothing to do with where the DLL is, it has to do with the fact that either
The XML payload namespace and root node does not match any schema
You have two or more schemas with exactly the same namespace and root node that match.
If you don't have any namespace on the XML, then it will try and match on Root node only, but again if you have more than one schema with the same root node, it will fail.
What you need to do is look at the suspended message and look at it's context properties and see what it's Message Type is, and compare that against the schema in BizTalk. There should be exactly one that matches.
vs
But to answer your question,
The source location is usually just the path of where the DLL was when it was initially imported in Dev.
the %BTAD_InstallDir% is the directory you chose when importing a MSI, the default location is C:\Program Files (x86)\Generated by BizTalk. However that is just where it puts it initially
Yes, in the end the actual one it uses will be in the GAC, which is under C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Note: If the DLL has been previously been deployed and you are deploying a new one then make sure you restart the host instances afterwards, as it will cache DLLs in memory for a period.
EDIT: I found a way to get it to work locally, but on Azure I still get System.IO.FileNotFoundException on that assembly.
My question might seem like a duplicate to this question here. But it is slightly different, I have already tried that solution and it did not work. Here are the details.
I have an ASP.NET MVC App that has a Reference added to a third party CLR DLL. That third-party DLL requires a native DLL which it invokes. Now if I had control over where the Shadow Copying occurs and what is copied, I would be in paradise. The Shadow Copying misses copying that native DLL despite it's Build Action set as Content and Copy To Output Dir set as Copy Always.
So I searched internet and ran into this discussion on SO, which is same as what was mentioned earlier. I tried adding the code that sets the PATH Environment Variable inside Application_Init and Application_Start of Global.asax, I set the breakpoints in both the methods and to my surprise I get the ASP.NET Error Page before it even hits the breakpoint. This leads me to believe that the referenced assembly at the time of binding hits the native DLL and invokes it. What can I do? Can I delay the reference binding somehow?
EDIT: Yes we can, I opened the Referenced DLL's code which was written in Managed C++, I adjusted the linker setting to Delay Load the Native DLL and now my Application_Start executes first. Yayy! but that does not solve the same problem I am having on Azure
Here is the test solution with DLLs
Here is the source code for the Native DLL
Here is the source code for the Referenced Assembly that uses the Native DLL
To download the Native DLL distribution, Go to their distribution page, choose the windows archive with the bitness you desire (I am using 32-bit), and you will find amzi.dll inside APIs/bin directory.
Actual problem was the wrapper DLL not recognized on Azure server because of lack of support of earlier frameworks and toolsets, as well as Debug CRT.
I used XDT/Application_Start to set the PATH environment variable to include the location of my native DLL
I upgraded my Managed C++ Wrapper DLL to use Toolset 14.0 and .NET 4.6.2
Used Linker Setting of /DELAYLOAD on Managed C++ Wrapper DLL
After downloaded the DLLs and source code which you provided, I found that the native DLL depends on x64 platform. Firstly, we need to change the Platform property of our web app to x64 using Azure portal. If the platform button is disabled, you need to scale up your web app plan to Basic level plan or higher level.
In addition, the original path may end with “;”, so we need to check whether it contains “;” and append right content to it. Code below is for your reference.
string path = Environment.GetEnvironmentVariable("PATH");
Trace.TraceError(path);
string binDir = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Bin");
Trace.TraceError(binDir);
if (path.EndsWith(";"))
{
Environment.SetEnvironmentVariable("PATH", path + binDir);
}
else
{
Environment.SetEnvironmentVariable("PATH", path + ";" + binDir);
}
To test whether the path is set successfully, you could add a page to test it.
public ActionResult GetPath()
{
string path = Environment.GetEnvironmentVariable("PATH");
return Content(path);
}
After path is set, the native DLL can be load successfully on my side.
On my end I added a throw new ApplicationException("Test") at the beginning of Application_Start and instead of getting my test exception, I was getting the DLL load error.
It means the setting path code will not executed. To fix it, you could remove the native DLL reference from your web application. Now your application could work fine and set the path environment variable. Then you could add the native DLL reference back.
Another way to do it is that we could create a webjobs and set the path environment variable in webjobs and deploy this webjobs before deploying your web application.
I am using 32-bit distributions, my native dlls depends on x86/32-bit.
If you use 32-bit distributions and the platform targets of your CLR DLL and your web application are set to "x86 or Any CPU", you won't need to change platform to x64 in web app. Please change it back to x86.
I have a Biztalk application that is basically a housing for a schema that other applications are using. I now want to remove this application, but am unable to from the BizTalk Server Admin Console, when I right-click --> Remove I get an error that says
Could not load file or assembly <assembly_name>.dll or one of its dependencies. The system cannot find the path specified (mscorlib)
followed by:
The system cannot find the path specified (Exception from HRESULT: 0x80070003)
So I go to remove the assembly from the Application and get the exact same error. I remove all references to it in other biztalk resources and still the same error when trying to delete the application or resource. I did notice that in the Modify Resouces dialog of referencing assemblies, this rogue assembly is listed as a dependency status of Not Found.
The strange thing is, when Messages come through, the resources which depend on the rogue assembly, still work fine and no errors are thrown (despite them using components of the assembly which shows as Not Found).
I have made sure to check the GAC and the assembly is loaded to it.
So now I have to ask:
where is Biztalk actually looking for this assembly?
is there a way I can just force a deletion of this application?
why does it care if the assembly is not found, when I'm trying to delete it?
why does it show as Not Found, yet still work?
Thanks.
I think the key is "or one of its dependencies." If it's a dependency it may be using the standard windows mechanism for finding a dll. It searches the current directory and the windows directory for them.
"where is Biztalk actually looking for this assembly?"
Look in the 'resources' section of your application in the biztalk management console. It shows a column with the location of the assembly.
I'd stop all the host instances/orchestrations, and then unload all your stuff from the GAC - if messages are actually still going through then stuff is still loaded that is using your schema.
I want to make a "properties style web form" that shows the application version for various .NET applications.
If I know the URL e.g. /someapp/default.aspx is it possible via reflection to execute that page and figure out the assembly version?
It's quite easy to find the executing assembly version, but without modifying the other application, is it possible?
Both the property page and the other application is running on the same server and in the same application pool.
Update: I've had some luck with
var url = "~/SomeApp/default.aspx";
var appType = System.Web.Compilation.BuildManager.GetCompiledType(url);
But navigating appType to find the assembly file version is not the same everytime.
Without modifying the web application to expose the version number through some URL-based retrieval (a simple page GET being the easy, obvious one), you're going to need to find a way to figure out where the DLL for the web application is from the URL.
If you can know the DLL's location, either by some convention (e.g. /appX/ is always at D:\Sites\appX\bin\appX.dll) or some configuration (you manually enter where each URL base's DLL is in a database), then you can retrieve that DLL's assembly version using the following code:
Assembly assembly = Assembly.LoadFrom("MyAssembly.dll");
Version ver = assembly.GetName().Version;
Code taken from this question.
Edit:
I've had a little look around, and there are some APIs to inspect the IIS configuration, so this is certainly a route to explore if you're trying to get from the URL to the assembly location. This question has an example of getting the physical path from the application/site name, for example. Microsoft.Web.Administration is the assembly to explore.
The ASP.NET engine streams nothing but HTML, javascript, etc.. to the client. There is nothing left of the assembly that gets passed in the response that can show what version of .net/asp.net that the application is running unless the developer on the server side adds it.
That said, you can gather some information from a utility at http://uptime.netcraft.com/up/graph that will give you some server information. Not down to the assembly version, but this is as close as I believe you are going to get.
You may implement custom HttpModule, put it to the bin folder of each application that you wish to monitor and append register this module in web.config files. In this module for example you should handle request, retrieve all required information and put it to response cookie.
regsvr32 filename.ax
I just see it said something installed successfully,but what's the whole story?
COM that is widely used in Windows relies on registration. A component will provide type libraries, interfaces and classes. Each of these are defined by a GUID to uniquely name them. COM components can also defined ProgID's that are kind of shortcuts to the unwieldy GUID's.
All this information is stored in a special registry hive on the computer named HKEY_CLASSES_ROOT. Use RegEdit.exe to view it. In particular you can find type libraries in HKEY_CLASSES_ROOT\TypeLib, interfaces in HKEY_CLASSES_ROOT\Interface and classes in HKEY_CLASSES_ROOT\CLSID. Some of the information in the registry will contain the path of the actual DLL with the component allowing Windows to locate and load the component when it is requested.
When you install a COM component it is necessary to create the correct registry information. By convention the DLL can provide two exported functions:
DllRegisterServer
DllUnregisterServer
When you execute RegSvr32.exe MyComponent.dll the RegSvr32.exe executable will attempt to call DllRegisterServer in MyComponent.dll. The DLL is then supposed to create all the necessary registry entries to allow the component to be used.
In a similar way you can use RegSvr32.exe /u MyComponent.dll to unregister the component. That will remove all the information previously added to the registry.
Windows relies heavily on COM and it is very important that COM registrations are up to date. Unfortunately there is nothing that blocks you from deleting an already registered COM component. This will leave dangling pointers in the registry pointing to the no longer existing DLL. You can't even unregister it since it no longer exists.
Another problem is when two different applications requires different versions of the same component. The registry can only point to one of the two versions, and this may cause one of the applications to fail.
Microsoft has created fixes for these problems. It is much better to provide an installer for the COM component that is able to repair and uninstall the component if it has been deleted. You are also able to create side-by-side installation of the same component in different versions.
It basically calls into your dll (named filename.ax in this case) and call its "DllRegisterServer" method.
In the case of directshow filters, it might "register" those filters in the windows registry so that directshow knows about them.
ex: https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L698 calls
https://github.com/rdp/directshow-demo-audio-input-open-source/blob/master/acam/virt_audio_all.cpp#L631
Though there are more simple versions out there.
regsvr32 registers DLL's and EXEs into the Windows Registry (usually COM Type Libraries, Class IDs, Interface IDs etc). You can use regedit to navigate the registry.