We use Windows Search in our application and need a way to detect is folder indexed.
I know 2 ways to do it:
1. Using Microsoft.Search.Interop.dll library.
2. Using Windows Search Sample Code (maybe a bit changed) as an .exe file called from C# application.
These two solutions need using an external file (.dll or .exe) but I need a simpler solution because it will be simple new optional SEARCH feature to a WebDAV server generated by wizard for our clients. Besides Microsoft.Search.Interop.dll is for .NET 2.0 and there can be a problem using it from IIS under .NET 4.0 pool (depending on pool settings).
Is there any way to use ISearchCrawlScopeManager interface without linking to any .dll (just to COM) like it was made in Crawl Scope Command Line C++ example?
UPDATE1: Looks like ISearchCrawlScopeManager interface is located in Search Interface Type Library. It isn't done yet, but I'm close. Thanks to Hans Passant.
Let me start by saying that I don't know what I don't know at this point, so rather than specific answers, I'm also looking for better questions to ask, I think. My .Net/C# is solid enough, and my C/C++ is meh.
Lately, I'm finding that there are no libraries in the standard .Net framework to accomplish certain tasks, and while it's easy enough to download a third party library, I'd like to understand how to do it myself if one doesn't already exist.
In one recent case, I need to deal with MIDI in windows at a relatively low-level, and I accidentally found out that "winmm.dll" is the library I'll need to use by downloading a .net wrapper for MIDI and browsing through the source. I understand that I'll have to make a wrapper class and do the whole P/Invoke thing to make that happen.
The next thing I did was to search for documentation on the Windows API to figure out what was going on in the mystery box of "winmm.dll," and to my delight, there was a whole Windows SDK that I was able to download and read through. I went through the "getting started" section of "Windows Development" which covered some of the basics via C++. It talked a bit about COM, windows header files, and I know enough C++ to get the gist.
Now, I need help connecting the dots on a few issues:
1) The Windows SDK, so far, seems to suggest that I want to program to specific header files rather than the dlls themselves, but the .net wrappers I've found typically point to a specific .dll rather that a header file...
/// <summary>
/// Returns the number of MIDI input devices on this system.
/// </summary>
/// Win32 docs: http://msdn.microsoft.com/en-us/library/ms711608(VS.85).aspx
[DllImport("winmm.dll", SetLastError = true)]
public static extern UInt32 midiInGetNumDevs();
I was under the impression that a header file and DLL needed to be in the same folder, but the windows SDK includes a folder with all the windows header files, and no DLLs (I'm guessing the registry comes into play here for mapping to specific libraries?)? How do those header files eventually get mapped to actual libraries, and why does it seem like I don't even need to deal with header files to create a .Net wrapper?
2) I can't seem to find documentation on winmm.dll, but I have found references to the functions I'll likely need in the "Windows API" list in the Windows SDK, and I'm pretty sure that the code for those functions are in winmm.dll. How do I find the documentation for the specific libraries I'll need to begin creating my wrapper? If I didn't know that I was going to need winmm.dll to access windows MIDI functionality, how could I have figured that out myself?
3) Some DLLs are COM, some are plain windows DLLs, some are .net DLLs... how can I tell the different going forward? It seems that creating wrappers for the former two would require a different approach.
4) There is no page on MSDN for "Winmm.dll" listing all of its API, and I assume there's a good and practical reason for that, but I'm not sure what it is? I'm used to .Net land where I can figure out what a library does and how to use it almost without effort.
Thanks in advance for any insights.
The bible on this is Adam Nathans excellent book '.Net and COM the complete interoperability guide'
Includes PInvoke and several audio-type examples
1) The windows API documentation includes the header, library, and dll file for each method/enum/etc. I just didn't scroll down far enough when I read through to notice this. A header file doesn't necessarily have to be in the same directory as the dll; its contents are simply copy/pasted into the .c file when the program is compiled. The part I was missing here was the linking stage of compilation which I read about here
2) The documentation was there--I just had to look for it a little bit harder.
3) How can I detect the type of a dll? (COM, .NET, WIN32)
4) The api for audio could theoretically span multiple dlls, so the best course of action is to find the API documentation, find the methods you want to wrap, then figure out what dlls those methods are in, and then import each of those DLLs.
I wrote an app on my iPhone. It's a more portable and smaller version of my pc software. I activated the File Sharing feature on my app so now I can transfer files through iTunes. But I want my pc software to be able to read or write files to that shared folder on my iPhone without having to do it manually through iTunes.
I have big constraints:
I can't use a Jailbroken iPhone/iPod/iPad
The vast majority of my customers don't have Internet access (It's a farm management software so even cellular are not available in some area)... :(
I heard there is a way using Manzana and MobileDevice.dll (itunesmobiledevice.dll). I don't really know how to use these dll. I tried to use Manzana a little but I can't access my folder since it's not a jailbroken iPhone.. Can someone help me with a little bit of code example?
Or is there other ways to make my iPhone app communicate with my C# application using the USB cable without internet access or Wifi?
mobiledevice.codeplex.com. This project should let you send and retrieve files from the phone
I'd suggest seeing if you can use the iTunes scripting interface. Add the COM reference iTunes 1.1 Type Library to a project and you can control many parts of itunes automatically. I can't find the documentation for it, but you can play around with the library and see if there is something to access the file sharing section.
Here's a decent introduction to using it:
http://www.codeproject.com/Articles/7723/Controlling-iTunes-through-COM
I’m hoping someone can help me track down why our WER is not working as I expect it to.
I have a large .Net 2.0 application that usually runs on a Windows Embedded Standard 2009. This application is made up of a Core C# application that uses several C# dlls some of which in turn use other c# dlls and some C++ dlls.
I have uploaded several mapping files (for different versions) to the Winqual website, and am receiving events corresponding to these mappings. However none of the events are based on the Managed C# code, it all seems to be based on the unmanaged C++ code. I have triggered some crashes in the Managed c# code and they have been sent to Winqual, but they don’t seem to be showing up on the Winqual website.
Does anyone know why this might occur?
I'm writing a WPF program in C# that needs to render a set of files in a file browser to the end user. The ExplorerBrowser control found inside the Microsoft Windows API CodePack contains much of the functionality I need... e.g. thumbnails of different sizes, sorting, browsing, etc...
The catch is that the files are not coming from the disk, but are available over a custom network transfer protocol.
I was originally thinking that I could simply extend the ShellObjectContainer class and ShellObject classes to provide the features I require, by essentially building an Adapter. However I've run into difficulties because these classes use internal constructors.
Overall it's looking like this API is rather hostile to extension, is there anyway to extend these components to do what I need, or am I better rebuilding much of ExplorerBrowsers functionality by creating a custom WPF component, perhaps by extending ListBox?
Yes, this certainly wasn't made to be extensible. Hard to see how you could get anywhere at all unless you create your own shell namespace extension. So that it is viewable in a shell window. Doing so is quite brutal in managed code, the shell's COM interfaces derived from IUnknown are very hard to use. Which is what the wrapper classes in the API code pack is doing to get a browser window in a managed program.
Creating the shell namespace extension is the greater solution, your custom files would be visible in a regular Explorer window as well. But write that kind of code in C++, both because it is so much easier to get the COM code going and to avoid injecting the CLR in any program that uses a File + Open dialog box. Although that is now technically supported by .NET 4.0