I would like to mimic the behaviour of a VB6-Active-X-Exe.
To do that, I have created a new project and set its settings to "COM Visible=True".
I can now add this .exe to my main application, and I can call it, call functions in that .exe, etc.
However, it is not really out of process, I think.
I would therefore like to investigate more about such an .exe's behaviour.
But I did not find any official documentation on it.
Can somebody tell me where to find more info?
Thank you!
Out-of-process COM servers (ActiveX EXE's) are not as easy to create with VB.NET as they were with VB6. When you reference a .NET executable (as a .NET assembly reference, not as a COM reference) from another .NET project, it always treats it as in in-process library. The .NET Framework has no direct equivalent to COM's out-of-process servers. Typically, in such scenarios, it is recommended that you create a WCF service, a web service, or use .NET remoting. WCF services are preferred since they use the most modern technology of the three.
However, since .NET supports COM interoperability, it is technically possible to create a .NET executable which can be registered as a out-of-process COM server. Then, when another .NET project references it via COM (rather than as a .NET assembly reference) it will run out-of-process. Microsoft provides an example of how to do that here.
However, if you don't need it to be COM (so that it can be used by non-.NET applications), I would recommend that you go the pure .NET WCF service route.
Related
I really want to develop using the WCF Service Library template, but I am concluding that it is not available on the express version. Can anyone confirm? I've tried the installVStemplates, and re- installing the software. No luck it seems. Am hoping I might be wrong somehow.
A WCF Service Library is, in essence, a class library (DLL) that contains the service contract and its implementation (or just the implementation if the contract is in a separate project).
While the WCF Service Library template is a convenient way to create a WCF Service library, the only things it adds are the IService1.cs/vb interface, Service1.cs/vb implementation, some boiler plate code, and references to System.Runtime.Serialization and System.ServiceModel.
If you don't have the template, you can do the following:
Create a new Class Library in the language of your choice.
Rename Class1.cs to your service name.
Add an interface for the service contract.
Add a reference to System.ServiceModel and System.Runtime.Serialization (the latter if you'll be using DataContracts).
I haven't used the express editions since 2010, and I don't remember if you can create class libraries with Visual Web Developer Express, so you might need to use Express 2013 for Windows Desktop.
It's a little extra work without the template (about 5 minutes or less), but you can still do it.
Im required to write a Silverlight application using WCF.
I'm also required to use Dependency Injection to gain access to this service in another library.
(I add a Silverlight enabled WCF Service)
The problem is in trying to use Dependency Injection (Prism/MEF in this case). When I make a Silverlight Shared library that will have interfaces for this service, I cannot add this library in the ASP.Net project due to the fact that it is Silverlight library. If I make a non-Silverlight library I cannot add that library to other projects to share that common interface.
Basically I need a library I think to share between projects in Silverlight so I can do this service injection.
Any information is appreciated
As slugster said - this done via linking to windows library files from silverlight library.
You do it as described here: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
I just wanted to add.. Since you go there - what you need is another Framework/Technology. Usually those classes you talking about depend on other classes/namespaces that live in windows only or silverlight only world. And then you need to transfer object data via wire.
Microsoft's solution to this - RIA Services. What it does - it takes your Windows classes and generates proxy classes on Silverlight side. Kind of what you need. And it works with WCF services.
There is 3rd party solutions like CSLA and DevForce.
I use DevForce and it does many things automatically, but instead of generating proxy classes - it creates links just like what you want.
Whether you realise it or not, your question is a duplicate of this one: Shared data object between WCF service and Silverlight app While not asked the same way, the answer is the same.
You need to create a separate project, and share the code files (as links) from one project to the other. Your problem is that the Silverlight project is compiled for a different runtime to the ASP.NET/WCF project. Because they cannot reference a common library, linking the shared files as mentioned is the easiest way to share code between the two projects targetting different runtimes.
I want to add non-silverlight assembly to a silverlight project,
is there any way to do this? or what will be the other option to do ?
As Andrey writes, it's impossible to add a non-Silverlight assembly to a Silverlight project. If you really need to use it, you have no option but to run it server-side. You may already have a Web project that goes with the Silverlight project, and if so, that's where you should add a reference to this assembly.
The technology used to make remote calls from Silverlight to the web project is WCF RIA Services. The page I linked to contains plenty of documentation and videos to help you learn about WCF RIA Services.
There are, however, a few situations in which this approach won't work. Perhaps none of them apply to your circumstances, but since you don't provide any details about this assembly, I can't be sure.
If, for example, your assembly contains some WPF controls and you want to add them to your Silverlight application, you're out of luck. You'll have to find Silverlight-specific equivalents.
If you'll be calling this assembly frequently, you might find your Silverlight application spending a lot of time waiting for the server to respond. This could slow your application down significantly.
If your application needs to be able to run out-of-the-browser and disconnected from the internet (a requirement of my current Silverlight project), you will also be out of luck.
There are a number of things that I can think of that should work reasonably well over WCF RIA Services:
sending email, calling web services or various other network-related activities,
talking to a database,
mathematical calculations.
It is impossible because Silverlight has different runtime from full .net framework. The common way to solve it is to create WCF service that will have access to that assembly and provide remote access for Silverlight application.
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.
I need to create a service. I know that you can do it with just a console application but it can also be done with ATL.. What are the benefits of the ATL Service vs a simple console application service? I understand that ATL is COM.. but what are the benefits of COM with the service.. thanks!
The service doesn't exactly benefit from COM, but rather the other way around.
By hosting your COM objects in a service, you get all the system features of services (startup before users log on, controlled policies watchdog, configuration of identity, etc.)
ATL gives you the opportunity to run your COM objects in a service context, as opposed to in-process (DLL) or regular out-of-process hosting. COM+ is another alternative for customized hosting.
If your service is just a background service, adding COM support could give you simple programmability, but otherwise I don't see any benefits.
So, I'm not sure that answers your question... The question feels backward :)