I asked a question earlier asking how to use the Windows 7 taskbar progress bar without the .dll files, but I realized that in VS2010 you can embed a .dll into your application. I set this option to embed to true, but when trying to use the code for said .dll, I get this error:
Interop type "Windows7ProgressBar" cannot be embedded. Use the application interface instead.
Not quite understanding what I have to do, I finally found a single .dll which is only 20KB (instead of the three required for the Windows API) and I can't quite use it yet.
Any help is appreciated!
The VS2010 option named "Embed Interop Type" only works for COM interop libraries. Not sure what "Windows7ProgressBar" might mean but it certainly doesn't sound much like an interop type. The native COM interface name is ITaskbarList4. Perhaps you are trying to embed a class wrapper for this interface, that won't work.
Consider using the ILMerge tool to combine assemblies.
Related
I have a dot net dll which uses System.Drawing.dll for using classes like Bitmap, Rectangle,Size etc.. But my dll cannot be used on xamarin... Plz suggest me what else should I use in my dot net dll for using Bitmap etc.so that it can run on xamarin.
Your dot net dll is complied for specified platform, such as Windows. so you cannot use it in other phone OS. It is no way for you to directly use dll in Xamarin unless you build it for portable class. But portable class is a generic class base, it lack of lots of classes. Such as Bitmap, it is different in different OS like Nick Turner said, so you will failed to build your source file.
The best way, you can reuse some none-platform dependent code in you dll, but for others, you need to write new code in each Android, ios, winphone project. So the Xamarin is not so wonderful for writing once, using every where. There is still lots of work in Xamarin, especially for platform specific code.
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
I'm looking for a missing COM interface X which I suspect is defined in Y.dll. I can peek at this presumptive interface using
grep X Y.dll
which says "matches". Hurrah, suspicion confirmed!
Alas, when I use the Object Browser in Visual Studio Express, trying to add Y.dll to my Custom Component Set, I get the error: "Some components could not be browsed" in a pop-up window.
So what are the reasons I can't browse this dll? Can the COM interfaces deliberately or accidentally be protected, hidden, secured, or obscured? Obviously I need a primer!
Officially, all Microsoft knows about this seems to be generally devoid of insight:
This error generally occurs when you attempt to add a file type that does not support object browsing, such as .htm
and .txt files, in the Component Selector dialog box. The Object Browser supports file types such as .bsc, .olb,
.tlb, .dll, .exe, and .ocx.
Seriously, what are the reasons for a dll or exe to not support object browsing? Any pointers to tutorials or books would be appreciated by this beginner! Thanks.
COM Object browsers rely on metadata (type libraries) exported by COM servers (dll, exe, ocx, etc).
The problem is that COM Servers are not required to export any metadata about which interfaces it implements. Unfortunately I have found quite a number of such servers (so one needs to know which CoClasses, Interfaces, etc are supported by other means).
Check if your COM Server (y.dll) contains a resource called "TYPELIB" similar to:
Hope this helps.
What is this Common Language Runtime that I've been hearing about?
I've recently started a project to create my own, small, personal windows application. I've used DirectX for drawing in the window and such before, for games and whatnot, however this time, I wanted to make it a more standard style application, with menus, and selectable text, and right clicking.
I've searched, but I found no information on how to actually write code for such things, I've only found things telling me to use the drag-and-drop form interface, for windows.
Anyways, I've found that using the forms, actually lets me see the code behind it, too, so I guess I could learn that way....
...but its forcing me to compile using CLR. Why? What is CLR? Can I not create this style of windows application without it?
-Stefan
CLR (Common Language Runtime) is a Virtual Machine. Whenever you compile your .Net programs they are converted into an intermediate language whereas a regular compiler would compile to native code of the target platform. Now whenever there is a CLR implementation available for an OS your program will run on that OS. This is how your .Net programs are portable! Read more here http://en.wikipedia.org/wiki/Write_once,_run_anywhere
The CLR is the runtime for the .Net framework.
You can only run .Net code on the CLR.
Since WinForms is a .Net library, you can only use WinForms in .Net.
How do you call IFileOpenDialog and IFileSaveDialog from VBA?
According to Microsoft, applications written for Windows 7 and later should use IFileOpenDialog/IFileSaveDialog API calls instead of GetOpenFileName/GetSaveFileName (see Using the Common File Dialog). This is especially important for full Library support.
Short answer: it's probably not worth the effort.
Longer answer: the CFD interfaces don't extend IDispatch, which makes them impossible to call via late binding from VBA. That doesn't mean they can't be called from VBA, but it means they require a typelib to describe the "shape" of the IUnknown-based CFD interfaces. Unfortunately, Microsoft doesn't provide the CFD interface definitions in a typelib. You can roll your own typelib by reverse-engineering the header files (or try to find the original IDL in the SDK), but you'd then have to register that typelib on every machine you want to use it on (the tools for which are not shipped on the machine, unlike regsvr32 for COM stuff). Assuming you did all that, you could then reference the typelib from VBA, and conditionally call it on Vista or higher OSes. You could also shim through to a small .NET assembly that would create a System.Windows.Forms.FileDialog-derived type and marshal the results back to VBA- that would be much easier, but still more-or-less require that you register the assembly on every machine (or use C++/CLI or other hacks to export a managed DLL function), and it requires you to take a .NET dependency.
They sure didn't make it easy... :) Good luck!