Is there a technical advantage in netoffice by using IDTExtensibility2 vs ComAddin in netoffice? Or do they both accomplish the same thing (although via different paths)?
I'm aware ComAddin inherits from the IDTExtensibility2 interface - I guess my questions is simply - why would I inherit directly from the interface and not from the ComAddin class? More control?
NetOffice doesnt use or works with PIA or VSTO(no need). This is one of advantages from NetOffice.
The IDTExtensibility2 interface is the common interface for COM based addin in MS-Office. The office application creates an instance from the addin(based on registry informations) and comunicate trough this interface with the addin. you can create an office addin just with implement these interface. (all solutions, addin express, vsto, netoffice do this behind the scene)
The COMAddin base class in NetOffice is a top-of wrapper to deal with Office trough the IDTExtensibility2 interface and handle the typical infrastructure tasks for you(register/unregister and so on). VSTO does basicly the same but you never see the base class here(during the codeprovider magic, but you can see this in IL Spy oder Reflector)
The COMAddin base class makes it a bit easier to create an office addin and reduce infrastructure code to be more familar with VSTO - thats the whole idea. Your choice to use it. If you have no exceptional requirements, its a good idea what i find.
ComAddin requires you to have Office installed but NetOffice works with just PIA(Primary Interop Assemblies).
Extracted from this link
An Office COM add-in is an in-process COM server that is activated by an Office application through the COM run-time layer. Therefore, developing a COM add-in in .NET requires that the add-in component be implemented in .NET and then exposed to the COM clients (that is, the Office applications) through the COM interop layer.
Related
I was looking for a solution to sign XML using unexportable private key (this require passphrase/secret password to be informed by user input for create the hash using it) contained in usb token (smartcard etc) for a web application. I have made a c# class library to make this but obviously the code is executed in server-side, so I can't access the usbtoken/smartcard of the client over internet, unless it's plugged in the server pc (so my solution may be installed in local network of my customers and the usbtoken plugged in server's usb. It's working like that today but I want to change this for the customer use its token in his machine)
I have created a code using SignedXml, X509Certificates and other classes, to achieve this, but I was looking for equivalents in silverlight class library for encapsulate all this things and execute it in client side, but unfortunately SignedXml can't be used in Silverlight (not exists..).
I have created an ActiveX for doing this successfully but my solution now only works in Internet Explorer/Windows, and it's not very easy to maintain because of my business logics.
Anyone can help me with this please? Any suggestions are very welcome.
If I can port my activex solution to silverlight, or if its possible to do that using other MS Technology that can be executed in other browser/OS.
Sorry for bad English, not a native speaker. Thank you.
Java applet is a better option than the ActiveX.
Silverlight won't give you access to certificate storages, and its development has stopped (Silverlight 5 is officially the last version).
Our company offers a ready to use solution for distributed cryptography which includes ActiveX, Java applet and Flash module for client-side activities. This solution is discussed in details in this answer.
Is it possible to include a .net 3.5 framework DLL in classic asp?
You will need to expose this .NET assembly as a COM object. This could be done using the regasm.exe utility. For this the types that you need to use or the entire assembly must be decorated with the ComVisible attribute.
Then consume the COM object from classic ASP as you would with any normal COM object.
Yes, it's called creating a COM-Callable Wrapper.
Here is the MSDN Documentation
The link that pops up for the Code Project article in Google is, surprisingly, not the better one. You'll want to check out this one: Exposing .NET Components to COM It's the best. Complete step-by-step tutorial.
It's worth noting that in a former life I had to develop and support a .NET application which was exposed to some COM-based integrations - and simply slapping ComVisible on my classes was putting me in a world of hurt. Pay attention to the author's explanation of the Interface Types in that article... that article is a gem.
Excerpt:
Previously I was using AutoDual,
however Heath Stewart[^] pointed out
this was not the best method to use as
it can create version-related problems
in the long run. After reading a
little more I changed the code to use
ClassInterfaceType.None which forces
our class to gain access only through
our interface. This keeps everything
viable during changes to the class in
the future.
How do I access a COM component from an ASP.NET page. I added reference to my ASP.NET project.
The actual dll I got from the 3rd party is ePadIIu.dll but when I added it to the ASP.NET project it shows as ePadIIu.interop.
I want to access all the methods and properties in the component.
The sample I received from the 3rd party software uses vbscript to access all the methods.
How do I use those methods in the code behind from default.aspx.vb.
When you added the reference to the COM component from your ASP.NET project, Visual Studio ran it through tblimp (type library import utility) to generate an interop assembly for use with .NET. By convention, it named it ePadIIu.interop.dll.
If you view this reference in the Object Browser, you should be able to determine the namespace you will need to reference, as well as any of the classes, properties and methods exposed.
Your using statement at the top of your *.cs might look something like this:
using ePadIIu;
Caution - Slippery When Wet
VB COM components are notorious for being compiled using a Single Threaded Apartment (STA) - though not always the case (if I remember correctly). If ePadIIu happens to be a STA COM component you might experience:
Slower performance
Possible memory leak due to blocked finalizer (not trying to be all doom and gloom, just seems to happen more often than not)
References discussing the problem:
COM Interoperability in the .NET Framework
Running ASMX services on STA Threads
Developing High Performance ASP.NET Websites
ASP.NET Hang and OutOfMemoryException caused by STA Components
Good Luck!
Z
Like the topic says, can ASP Classic use registration free components? This is on Windows Server 2003. If so, how do I go about doing that?
If not, could anyone please provide some alternatives?
By Registration Free I assume you mean DLLs that are not registered as ActiveX components using regsvr32. If that's the case then no, not directly from ASP 3.0 though you could use it remotely via DCOM using CreateObject. The reason why is without registering it there is no ProgID to reference to find the ActiveX component.
By alternative, I guess you don't mean components that do require registration? 'Cause there are loads of those...
A less common way of using COM with ASP that is quite convenient is to use Windows Scripting Components (WSC). From 4GuysFromRolla:
One of the biggest disadvantages of
developing COM components using one of
these high-level languages is the
time-intensive process of altering an
existing COM component. For example,
say that you are developing a COM
component. You add some properties and
methods and start using it on your
site. Now, say that you wanted to add
a new method. After adding this method
you would have to recompile the COM
component, reregister it, and stop and
restart the Web server...
To solve for this annoyance, Microsoft
has created Windows Script Components,
which, as their name implies, are COM
components created with script! These
components can be developed with any
Windows scripting language (VBScript,
JScript, PerlScript, Python, etc.).
Since these components use script, you
can literally cut and paste your ASP
script into one of these scripted
components! Also, you can edit a
Windows Script Component's code and
the changes are automatically
reflected - no recompiling, no
restarting the Web server, and no
reregistering the component!
For more info, check out these links:
http://msdn.microsoft.com/en-us/library/07zhfkh8(VS.85).aspx
http://technet.microsoft.com/en-us/library/ee692823.aspx
https://web.archive.org/web/20210927201615/http://www.4guysfromrolla.com/webtech/050400-1.shtml
I have some basic experience in making Flex sites, but I think I have more use for Flex in making a desktop AIR application.
Anyway, I was wondering if it is at least possible to use C# alongside Actionscript/AIR? I can't find any example of this.
Also, can I use custom Flash components in a Flex app? I know I can use Javascript components.
Thanks
Your options with AIR are limited to HTML/JS, Flash/ActionScript or Flex. There's no support for other languages and frameworks.
You can create a C# console application and call this application from AIR.
var file:File = File.applicationDirectory;
file = file.resolvePath("CSharpConsoleApplication.exe");
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.executable = file;
nativeProcessStartupInfo.arguments.push("-arg");
var process:NativeProcess = new NativeProcess();
process.addEventListener(NativeProcessExitEvent.EXIT,onProcessDone);
process.start(nativeProcessStartupInfo);
In this way we have a C# application with AIR interface.
Slukse is correct -- it depends on what you mean by "alongside."
Obviously you can't compile C# code into a SWF -- that much we know. But you can certainly embed (as davr suggests) an ActiveX control into a .NET Forms app, load the SWF into that control, and use the ExternalInterface API to bridge the C# code running in the desktop app and the ActionScript code running in the SWF. If by alongside you mean writing server-side C# code to render data consumable by the Flex app, then of course, you can do that, too -- there's plenty of documentation out there covering how to connect a Flash or Flex (or AIR, by extension) app to Web Services of a variety of flavors, including the relatively new-ish WCF stuff.
Another way to go would be to run a standalone C# desktop app (e.g., a service, console app or the like) and have that app listening over a certain local port -- then have your SWF talk to that app using the Socket classes. I'm doing something like this now (with Java, not C#, but the idea's the same) for a personal project.
If by 'alongside' you mean using c# as middleware to connect to your database (probably SQL Server), or to perform remote calculations then yes you can. You can connect to a c# service using remote objects. The midnight coders produce a product called WebORB that is fairly simple to use. Version 3.4 was a totally free version that should suffice if you are building desktop applications in Air. The next two versions are not free but basically offer no real advantage to you.
The only way I know of doing this is with C# web service programs and the AIR/Flex apps communicate with the web services.
The whole point of AIR is to enable web developers who know AS/JS to be able to easily make desktop applications which are automatically portable to win, linux, and mac. Hence why there is no way to connect it to other languages like C#, C++, etc, since web developers generally don't care about those languages, and if they were used, the app is no longer portable (yes, most languages can be ported to other OS's with some effort, but the point of AIR is that you write whatever you want, and it runs everywhere with no extra work).
If you want to combine C# and Flash, instead of trying to put C# inside AIR, what you should be doing is putting Flash inside a C# app. There are various resources for this on the internets, here is one I found in a quick search: Example: Using the External API with an ActiveX container. When you are searching, make sure it talks about the newer, more advanced ExternalInterface / External API method, and not the oldschool SetVariable/CallFunction/watch method. The newer one is much easier to use & has more features.
Also, yes, you can use custom Flash components inside a Flex app. Generally you just make a SWC inside Flash CS3 (or CS4), and then import that SWC inside Flex Builder (or Flex SDK, or FlashDevelop, or ...)
If you are making the components yourself inside Flash CS3, you should use the Flex Component Kit. It provides some features for you, and puts in the boilerplate code, to make your flash component play nice inside Flex. It's included with Flex Builder/Flex SDK.