Does anybody know of a good library for reading/modifying ms project files?
For me the COM interface also worked like a charm. There are a few traps, take care of the CultureInfo of your thread, set it to "en-US", there seems to be a similar issue as the LCID bug in Excel. Also call the methods of the COM from one single thread.
I had a look at your profile and could not judge if you know how to deal with COM under .NET or not. In our project just add a reference to the COM and then you should be able to use the methods. The MsProject API is quite low level (Database oriented) but proved to be quite reliable (that was not the case when I used Excel COM API).
I would go this way because then you do not depend on a 3rdparty library (only on MS) and you can do everything you could also do from within Macros. Other solutions might restrain you to what was implemented by the SDKs...
Does Aspose Tasks not do what you want ?
I know there is an example in the ILOG Gantt SDK that will load MS project files; I can't remember if it saves too, but it might help as a starter.
What about MS Project COM interface? I used it to make some web reports with it in the past...
The COM interface is a good bet as others have said. Microsoft have some more stuff here.
That said it might be easier to use MPXJ which purports to provide a robust and open API for manipulating various types of MS Project file.
You can use COM interface and you need to use a namespace"Microsoft.Office.Introp.MSProject"
Related
I am trying to write some plugins to work with the Terminal Services Session Broker Plugin Interface. I am very fluent in C# but I have not done any C++ since the late 90's. For the plugin I am writing I plan on communicating with a database and I would prefer to use System.Data.SqlClient to talk to it as I know it's ins and outs fairly well. I have the Windows SDK which has provided my with the .idl file for the interface (tssbx.idl). The SDK also provides a C header file (tssbx.h) and a C source file (tssbx_i.c).
I have never written a COM server before, and I have been having a lot of trouble finding resources on learning how to read a IDL file and turn it in to C#. Everything I find says "Use TlbImport" but that requires things like the block library to be in the IDL which tssbx.idl does not (nor its dependents) implement.
What would be my best option:
Find a tool for C# that is the equivalent to MIDL for parsing a .idl file in to a .cs file.
Learn IDL (I have been having trouble finding good guides to learn it) and write the whole thing in C# by hand.
Write a helper dll using the C files provided and have that call in to my C# dll for my .NET parts.
Re-learn C++, use the provided .h and .c files, and use the CLR to make my .NET calls.
Some other option I have not thought of.
The way to do what you're trying to do is to translate the IDL definitions into C# interfaces, then implement those interfaces as C# classes. You apply the appropriate attributes (mostly ComVisible, ClassInterface, and ProgId) to the classes you want to expose to COM, and use the regasm tool to register your assembly as a COM server.
Translating IDL into C# is actually not that complex; for the most part it maps pretty directly from IDL keywords to C# keywords and/or MarshalAs attributes. I have a series of blog posts on how to do COM interop w/out tlbimp, including one on how to read IDL. I don't know of any tools, specifically, that do a good job of this, but if its part of the Windows SDK you should always check pinvoke.net first in case someone else did it for you.
As far as your other options, 3 and 4 both amount to about the same thing. You cannot call managed code directly from unmanaged code unless it's done via COM Interop or a mixed-mode C++ library. In the first case, you'd still have to solve all of the problems of getting your C# assembly registered with COM for your C dll to call, so you may as well skip the middle-man. For the second, you are basically doing manually the same things that the runtime's interop code does for you, and using a language you're less familiar with to boot, which seems like a net loss to me.
Be aware, though, that loading .NET assemblies into an unmanaged context isn't always possible; for example, managed shell extensions are explicitly not support in Windows 2008. I don't know if the TSSBX interface will allow you to load managed assemblies as COM objects or not, so you'll have to be aware of that possibility. If you can't, then none of your options are going to work, and you'll have to avoid using the .NET Framework at all and use some other database access technology and write the entire project in unmanaged C++.
I am posting this as an answer because it is too long for a comment
From what I gather writing such plugins in .NET might raise problems later on - esp. in a scenario where more than one .NET-based plugin has to be loaded and the two (or more) plugins use different .NET versions (such problems has been expressly mentioned in the context of shell extenstions - I am just taking the reasons from that scenario as a basis for my suspicion...).
As to your option IDL itseld can't implement anything - it is an interface description language.
I would suggest using something similar to option #3 with some modification:
Implement the .NET part as a Windows Service and communicate between the C and the .NET via IPC - I would recommend using shared memory which is extremely fast and well supported with .NET4 .
I'm fairly new to programming with Interop.Excel and may lack the experience, but why is it such a pain to program with it? Casting objects everywhere, more or less no documentation on the methods (at least not in the code) and every method seems to return objects, so there is no way of telling what it actually does. Also, all arguments are objects to begin with.
Is there any good wrapper library out there that provides basic functionality (writing to cells, reading, creating sheets, deleting sheets, basic formatting and layouting) and does this in a good, clean and understandable (and by that I mean: well-documented) way?
PS: Working with C# and .NET-3.5
I'm using EPPlus and very happy with it. It's open source and free.
The owners offer support when ever it was required.
EPPlus on codeplex
Note that EPPlus doesn't support Excel 2003 format. .xlxs is supported while. xls is not.
Well this is quite pricey, but in my opinion worth the money if you are doing serious commercial work with excel. As well as being the fastest option, you also don't even have to have excel installed, anyone who has run excel on a server will understand why that is huge.
Http://www.spreadsheetgear.com
If you're having problems with using interop directly, you may want to try out OfficeWriter. It can do anything you've described above with Excel, and more. You can request a free trial. There's a fully documented api available at the documentation site.
DISCLAIMER: I'm one of the engineers who built the latest version.
Try ClosedXML, it wraps the OpenXML SDK to give a very intuitive way to create Excel files.
We have a COM interface declared and implemented in unmanaged C++. We no longer wish to maintain this assembly, but do need to make some changes, and still be backward compatible.
What I want to do, is to write all the new code in C#, and make it ComVisible. From this thread I see a reference to TreatAs to replace the old interface.
I was thinking along the same path as Jonathan Peppers regarding ProgId, Guid, etc. I will implement the exact interface as the old version as a wrapper to the new implementation. I am also thinking about adding MarshalAs attributes exactly as in the generated interop wrapper to be sure the data types will be the same, if possible.
Are there anything else I should consider while working with this? Anyone with experience doing this conversion?
EDIT: I do have the IDL file for the server. I am not sure if there is a way I can auto generate the code based on this. COM is not something I'm very familiar with.
EDIT Q: How should I deal with HRESULT used by existing clients?
ADDED: Figured I should point other readers to a different fix, which is not available for my scenario as I can't recompile all the .NET applications using the existing com:
Bjørnar Sundsbø
One quick way to get started:
Import your existing COM object into C# with tlbimp (or Visual Studio)
Load up .Net Reflector and get the generated interface to put in your new project
Implement the generated interface in C#
Switch any import declarations to export instead
This should get all your types and method signatures correct from the start. It is a great starting point for porting an existing COM interface to C#.
It seems to be by design to prevent managed COM object from being used from a managed client.
Here are some links to the same problem, as well as this thread, providing some solutions. Also take a look at the answer Jonathan Peppers provided to see how to start out if you only need to use it from unmanaged applications.
The only way I figure I could work around this, is a messy solution where I create the new code in C#, add a COM layer on top of that. Then create an additional COM layer as unmanaged C++ which accesses the first layer so, that my .NET applications can access it.
{Unmanaged COM exposing the original interface} => {Managed COM with rewrite of the original logic of the COM}. All existing applications will then access the "{Unmanaged COM...}". If I get desperate enough, that might be a way. For now I'm abandoning this approach and looking for other solutions.
If you can, recompile your managed application to use the new assembly, do so. You can still use that managed COM from VB6, unmanaged C++, etc. If you still need to reference as a COM from managed, you might be able to create new instances using the approach specified in one of the referenced posts, as long as you don't need to create an interop wrapper.
Sure, there's a type of project in Visual Studio that outputs a DLL that people can use. I know that. I'm just wondering what are some of the standards that devs will expect when using my DLL file.
I'll be providing a class that searches for movies in IMDB and returns results for a dev to consume.
Not a webservice, but a local DLL file. (I'm aware that IMDB frowns upon web scraping, but I'm also aware that they give permission to people if asked. My permission is already sent.)
How should I approach this?
Check out Microsoft's Design Guidelines for Class Library Developers.
Or the newer version of same (thanks to paper1337).
You're then interested in best practices when designing a class library. There is much to say to this thema.
One of the first and foremost things you need to do is to publish all your dependencies. Avoid any hidden dependencies in your code.
For example, don't rely on some key to be set in a shared key-value collection, such as Session. There is no way a user of your library can find it out.
If some method requires some service to be preinitialized, require a valid reference to be passed as an argument.
You need to provide a simple to use API, full documentation and worked examples as a minimum. If you can provide unit tests that would be a bonus.
Internally, you need to verify all inputs into your routines, as well as clearly document what configuration the user is expected to do. Solid exception handling is a given, and you should possibly consider some localisation support in there as well.
If you, or anybody, is serious about creating a good framework for others to use, check out http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321246756
What ever you make public, should remain public and their signatures cannot be changed in your next version and you must support it forever.
So, take care in establishing your contracts and document them with examples. Make public members only if it needs to be.
Easy-to-use API with appropriate class, method and property names.
API has been tested (e.g. unit tests)
Supporting documentation.
I just got handed an SDK made of C++ dll, lib, exe, and various .h files. I presume it is meant for C++ developers. The sample projects they provide with their documentation are all written in C++. I am able to spin them up with Visual Studio 8 (2005) and run them. They do control the device as advertised. However the project this needs to be used by is in C# .Net 2.0 and that is unchangeable.
My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution. My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
I've used COM objects in C# solutions before so once this is made, I can continue on from there without a problem.
However, I don't know what to do to make the COM object from the 2 .dll files, 1 .exe, 1 .lib file, 1 .xml file, and the 12 .h files. Is there a resource available to tell me what to do to make this happen?
My boss was a C++ developer and says all I need to do is to compile it as a COM object and then import the COM object into my C# solution.
That's true, however compiling it as a COM object is "difficult" (by which, I mean that you can't do it) unless it already implements the COM APIs (if it doesn't then you need to implement the COM APIs before you can build it as a COM object).
There are books (for example, Essential COM) which explain how to to create COM objects using C++, but it's non-trivial (for building COM objects there may be better books than Essential COM, and better/easier tools than C++).
I think you and/or your boss have 3 options:
Ask the vendor to give them to you as COM objects
Design a COM API that would wrap the SDK's API. Create a COM project (in the language of your choice) which exports this API. Implement these APIs by invoking the underlying SDK methods. To do this you may need someone who knows C++, or be willing to spend much, much longer than "an hour" on this project.
Forget about using COM; instead, build the SDK as a DLL, and use PInvoke to invoke it from .NET code.
My boss says it should take less than an hour to "wrap" there SDK up as a COM object, even for me with no knowledge of C++ compiling.
Based on what you've said I don't know of any way to make that happen.
Tell your boss if it would take him less than an hour to wrap it up, he should certainly do it: it would be a more efficient use of both your time.
I would also suggest ATL (not using attributes), but this is something which can take some time to get right if you're not experienced.
My boss says it should take less than
an hour to "wrap" there SDK up as a
COM object, even for me with no
knowledge of C++ compiling.
That may be true for an experienced C++/COM developer, but not for a beginner. I think your best bet is to use ATL. Take a look at the MSDN tutorial.
And do not use attributes.
This doesn't quite answer your question, but...
One option instead of trying to make a COM object is to use P/Invoke and just call the methods in the DLL.
This thread on the MSDN Forums documents how to make a DLL to call using P/Invoke.
Of course if you need access to a whole class (and make an instance of said object), this isn't going to be helpful.
It's good that the code compiles and runs for you. That said it's totally unfair to assume you can do this in an hour.
Have you checked to see what is actually being built by Visual Studio. There could be a chance that it is already building a COM object.
Investigate how the code is being called. I assume you have a .exe that you can run to test the code. Step through this in the VC++ debugger (it's similar enough to debugging C# code) and try to identify any API calls that match with your docs/expectations. This knowledge will be helpful if you try to go the P/Invoke route.
Something else to consider is SWIG. This is typically used by Python developers to wrap C/C++ code and provides some support for C#.
The managed C++ route is probably more advisable for experienced C++ devs because you need to understand a lot about memory allocation, for all but the simplest code.
I (well, really my lead and I) will first try using p/Invoke (via the DllImport feature of System.Runtime.InteropServices) against the SDK's dll the company provided. I'll let you know how it goes.
I think what you really want/need is C++/CLI, that way you can just build them directly into a managed assembly. The idea is that you write a pretty plain wrapper that looks like kind of a cross between C# and C++ and then it does the rest.