Windows-7 introduced a concept of virtual folder, called 'Libraries'.
I am working on implementing a Library with my custom action. The constraint is that, I have to stick to .NET version 2 for this :(
While looking around, I didn't find any native (c/C++) API for doing this. I am planning to use Interop (p-Invoke) to make a library once I get native APIs.
Could any one point to a link or documentation which might help. If somehow I can do this directly from c# (with .NET v2), that would be great.
Thank you,
John
The MSDN topics that seem most pertinent are:
Inside Windows 7:Introducing Libraries
Windows Libraries
Windows 7 Libraries: Developer Resources
The library features are exposed through COM so there's no need for P/invoke.
However, since libraries only exist in Windows 7, and since Windows 7 has .net 3.5 as part of the OS, I would recommend that you put this part of your application in a .net 3.5 assembly. In fact the API CodePack assembly already does this for you.
Of course, since the CodePack is also delivered as source you could extract the necessary parts from there and do what is needed in order to build it against .net 2.0.
The concept of "virtual folder" exists already before Windows 7 and has AFAIK just been "refined"... you write you want to do this with your own custom handler...
IF you want to implement such a "virtual folder" and integrate it into Windows so that other applications can use it as a "virtual folder" then:
To implement and install a "shell extension" (which basically are a bunch of COM interfaces):
Remark: If the system you are running on doesn't have .NET 4 then Microsoft recommended NOT to use .NET for this because of the inherent restriction with the older versions that one process can't run multiple framework versions at the same time. Depending on the OS etc. case it could be recommended to implement this with C/C++.
Even with .NET 4 as pointed out in the comments the code injection problem remains - i.e. if any .NET app prior .NET 4 and/or with a different .NET versions than your shell extension accesses the file open dialog for example it can/will fail.
To circumvent that you need to implement a native proxy DLL which gets loaded into the respective processes (like Windows Explorer) and communicates with your .NET implementation via IPC.
In this specific case you need to build a shell extension which implements IShellLibrary.
That aside the implementation of shell extension is a really tough job... some links with information / samples / source code / libraries etc.:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774328%28v=VS.85%29.aspx
http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-1.aspx
http://www.ssware.com/ezshell/ezshell.htm
http://www.codeproject.com/KB/shell/ratingcolumn.aspx?q=shell+extensions+c%23
http://www.codeproject.com/KB/shell/shellextguideindex.aspx
http://www.nirsoft.net/utils/shexview.html
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
To interact with a Windows 7 library see http://support.microsoft.com/kb/976027 and http://www.codeproject.com/KB/miscctrl/Windows7APICodePack.aspx and http://archive.msdn.microsoft.com/WindowsAPICodePack and http://www.codeproject.com/KB/cs/DDW7LibrariesLite.aspx . Some require .NET 3.5 but since 3.5 is just 2.0 plus some additional assemblies it might be an option...
Briefly searching in google, found this: How to programmatically manipulate Windows 7 shell libraries
if C# examples are not useful, it should be possible to export api methods used in c++ example.
Related
I'm planning to program an application (C#) which can draw some things on AutoCAD. After a lot of research I don't understand where i need to start. Can someone explain to me what ObjectARX is ? And if I need to use it ?
I want to create an application ! Not an AddOn (NETLOAD)
:)
Sry for my english I did my best.
CM.
Normally applications are independent processes. In some cases the processes may communicate with each other according to some standardized protocol to extend functionality.
Addons, or plugins typically refers to code that is run as part of another process. I.e. you write a library (i.e. a dll file) that is loaded by the host application. This usually requires that the plugin implements some set of standardized interface for it to work.
ObjectARX is according to wikipedia the standardized interface for autocad. It is however for C++ and not for .Net. There is facilities in .Net to use c++ code, and there is also some articles about hosting the .Net environment in a native c++ process.
If you want your "application" to run in a separate process you would need to write a plugin that communicates with your process via some form of Inter process communication method.
All the approach you suggest seem to be rather challenging since it involves several layers of communication that may cause problems. It would probably be significantly simpler to just write a c++ plugin since this is the intent behind the ObjectARX interface.
If you look in the folder where Autocad is installed you will see some managed DLL libraries.
You can create a C# .NET DLL application that references these libraries. Then, you will have access to the AutoCAD environment and can do what ever you want.
Research AutoCAD .NET to find tutorials and resources.
There is some info in the Tag Wiki but, in a nutshell, you cannot create a stand-alone application that directly references the SDK shipped with AutoCAD (or BricsCAD etc). You can automate AutoCAD via ActiveX or you need to buy an SDK from Autodesk (OEM) or the Open Design Alliance and build an app on top of that.
Anything that uses the SDKs shipped with the applications must be a plugin in the host CAD application.
I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?
Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.
I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.
I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.
I want to create a property handler in .NET. I have already implemented the IInitializeWithFile, IPropertyStore and IPropertyStoreCapabilities classes but I don't know how to implement their functions to create custom properties and display data. Can someone explain it?
I already know this: http://blogs.msdn.com/b/oldnewthing/archive/2006/12/18/1317290.aspx so please don't discuss about that.
Remark: If the system you are running on doesn't have .NET 4 then Microsoft recommended NOT to use .NET for this because of the inherent restriction with the older versions that one process can't run multiple framework versions at the same time. Depending on the OS etc. case it could be recommended to implement this with C/C++. BEWARE that even with .NET 4 MS says .NET-based shell extensions are not supported. To circumvent that you should implement a native proxy DLL which gets loaded into the respective processes (like Windows Explorer) and communicates with your .NET implementation via IPC.
That aside the implementation of shell extension/property handler is a really tough job... some links with information / samples / source code / libraries etc.:
IInitializeWithStream (highly recommended by MS instead of IInitializeWithFile !)
IPropertyUI interface
http://msdn.microsoft.com/en-us/library/windows/desktop/ff728898%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ff728869%28v=vs.85%29.aspx (sample code)
http://msdn.microsoft.com/en-us/library/windows/desktop/cc144125%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774328%28v=VS.85%29.aspx
http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-1.aspx
http://www.ssware.com/ezshell/ezshell.htm (commercial)
http://www.codeproject.com/KB/shell/ratingcolumn.aspx?q=shell+extensions+c%23
http://www.codeproject.com/KB/shell/shellextguideindex.aspx
http://www.nirsoft.net/utils/shexview.html
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
I know how to create a COM DLL (a Class Library) in C#. Is it possible to create a COM Surrogate EXE using C#?
This would be a standalone server capable of launching and hosting COM objects, which would then be accessible to COM clients.
The default surrogate process for COM - the thing that hosts COM DLLs, aka the COM Surrogate - is dllhost.exe. It is possible to create a surrogate process in C++. This article explains how.
But those APIs are not exposed in wrappers as part of the base class library in the .NET Framework. If you want to write to write only managed code, you need something else.
I see a couple options.
The Visual Studio SDK, a free download that is intended for devs who want to extend Visual Studio. Within that SDK, there's a class lib that has such wrappers. In particular, look at the ISurrogate class.
BUT, the VS SDK license says that the SDK is ok to use only for products that extend or add value to Visual Studio. I am no lawyer, but that is my understanding of the license, which is pretty clear. These terms means the VS SDK would not be useful for general app building.
The one remaining question is, exactly how do you use the VS SDK technically to produce a COM Surrogate using only C# code? Again, here I don't know. I looked in the docs briefly for guides on using the ISurrogate wrapper, but found none.
Use the code in this article.
The article explores a bunch of different aspects around COM and .NET interop. Towards the end of the article it offers source code for building your own COM server in C#, complete with all the p/invoke calls to CoRegisterClassObject() and friends.
I wanted to make same thing and found excellent project example CSExeCOMServer on All-In-One Code Framework. It actually reconstructs normal COM server logic by means of .NET and native calls to Windows API. But it looks all still overcomplicated. I suppose there is no simple and fast way to expose .NET objects as COM in out-of-process server and it is not the architecture of choice.
One option, if you want an out-of-process COM component, is to host a dll in COM+ via serviced components. This only supports dll though, but you could write a shell exe (for standalone use) that simply defers to the dll.
Not quite as simple as VB, but it works.
I do remember somebody showing me a more direct way (no COM+), but I can't for the life of me remember what it was...
I'm developing an application for a Windows based tablet PC. This application is pretty much a port of an application I already developed on a Windows Mobile device using .NET CF. I want to write the application from scratch, taking advantage of all of the knowledge I've gained in software development.
I'd also like to write this new application in such a way that if I so desire, I can modify my existing Windows Mobile app to use the new libraries. Ideally, I'll have a shared set of business logic and data access libraries, with the only real difference being the UI layer - WPF for the tablet version, and just a standard CF interface for the Windows Mobile app.
Taking this into account, I'll need to make sure that all of the projects I create are compatible with the .NET Compact Framework. Is there an easy way to ensure this? One thought I had was to use a Smart Device Project for each class library that I create.
As well as this, is it easy for me to reference these libraries written for a .NET CF application from a standard windows application?
Is developing an application for a tablet PC the same as developing any normal windows forms application? Is there a different version of the .NET Framework to take into account, or are tablets pretty much standard windows pcs?
There isn't a special version of .NET Framework for Tablet PC. The question of sharing code between Windows Mobile and Windows has been asked before and the accepted answer is excellent.
The tablets I've seen are running standard Windows with the "full" .NET, but I expect you can get some light-weight devices, too. One interesting possibility might be "client profile" (a subset of the regular "full" .NET dlls) - but I haven't seen much use of that myself.
CF and regular .NET share a lot of things, but ultimately there are differences; neither is a strict subset of the other. I've found that in general the only way to write code for 2 frameworks is to keep both active... for protobuf-net (which has this problem) I keep a project file for each framework so that I can quickly test that the build works everywhere (i.e. there are no missing methods etc).
You may find you need to use #if blocks to run slightly different code on the two frameworks, especially if you want to use "full" .NET features for performance reasons (that don't exist in the CF version). One way of making this easier it to hack the proj files to use recursive file inclusion:
<Compile Include="**\*.cs" />
Now you don't have to keep adding new files to both projects - it'll get picked up automatically (caveat: in the IDE you may need to unload/reload the project).