I have a legacy delphi dll.
I created a class library that imports the dll and registered it for COM interop.
I have an experimental Silvelight 4 application that calls the COM object and it works. The problem is: how do I deploy the COM component (and dependent delphi dll) and register the COM object on a client machine?
The COM component will need to be installed explicitly on the client machine. The standard Silverlight deployment does not (by design) support installation of COM components.
Typically, the COM interop in Silverlight is really intended to work with System COM routines that already exist on the system - if you're doing native code interop with native code deployment, normally, you'd just use a full desktop application developed with WPF.
Related
I've started working with delphi quite some while ago but I would say I'm still a newbie in all this.
So basically I tried creating REST Server, which can validate license keys. I got in working with Indy, but one thing bothers me. The GUI. The Server shouldn't have any kind of gui so it can work on any OS (Win, Linux, etc). Is there a way to make a REST Server without any GUI/FMX/VCL?
BTW: Working in Delphi 10.2.3 Professional.
Any advice is appreciated.
EDIT: I forgot to mention one thing: the server is supposed to run on an independent Data Center away from any user.
You can create the WebServer as a Windows Service.
You can use DelphiMVCFramework or any other Framework to create it.
With DMVC you can create console application, Windows Service, Linux daemon, Apache module (Windows and Linux) and IIS ISAPI (Windows).
With Intraweb you can also create Services.
Take a look at our mORMot Open Source REST framework, which works on Delphi but also on FPC/Lazarus.
FPC support ensures that you can target Linux with this free compiler. No need to upgrade to a newer version of Delphi Architect, which supports Linux, and is very pricey - and less stable (to my knowledge) since Linux support is quite new.
As you requested, the mORMot REST server has no UI part. You define your services as interface and class - like you do e.g. with DotNet - and you will have full JSON/REST support generated.
mORMot is used on production since years for very high performance and stability, hosted on both Windows and Linux. A version 2 is on its way, which would be even easier to use for new projects.
And you can create a Windows service or Linux daemon without using any third party framework. Delphi include everything you need. However, it is possible that third party framework will facilitate your programming. Don't forget you'll have to learn those third party framework.
Creating a Linux daemon service in Delphi
Creating a Windows Service in Delphi
In both cases, you can use the sample code you've found that make use of TIdTCPServer.
Environment
Visual Studio 2017 Enterprise on MAC, Mono 5.12.0.309
Problem
I've successfully built and packaged an Azure Function. Now, I'd like to call a SOAP Web service in the function (over which I have no control). I added a Web Reference to the published WSDL and tried to compile the function which resulted in a ton of errors primarily indicating "System.Web.Services" namespace is missing.
"System.Web" doesn't seem to be part of .NET Core 2.1 (that is referenced in the function project). How would I then add a reference to "System.Web.Services" assembly? Is there a NuGet package?
UPDATE
Part of this was my lack of understanding of what .NET Core actually is. Since I'm using .NET Core, I can't make reference to assemblies that are targeting .NET Framework. "System.Web.Services" seems to be one.
Now the question becomes, how one would then call SOAP Services from .NET Core application?
You can use the new WCF client side stack on .NET Core: https://github.com/dotnet/wcf
There is a good sample to a question on this thread: Calling a SOAP service in .net Core
I have a Windows Form application that deploys using Microsoft Click-Once. I would like to add a new feature to the application that in part utilizes a third-party DLL that happens to be obfuscated. During an initial test release of the application, the application wouldn't install. Initial research seems to indicate that Microsoft Click-Once and Obfuscated DLLs don't play well together. Is that the case? If not, is there a special way to get an Obfuscated DLL to install/work in a Microsoft Click-Once deployment?
Thanks!
I am a new in developing Metro application. And I have a question regarding external DLL for Metro.
As I understand project which implemented DLL(extension) should be include in solution for Metro application. And I should specify dependency into Package.appxmanifest. Only after that action I can use this extension in my Metro application.
But what about external DLL(extension)?
How to use DLL installed on system (something like load library for Desktop)?
Could somebody clarify this issue?
Thanks in advance.
A Windows Store App is sand boxed and can't access any system DLLs, or DLLs other than the ones provided in your project.
Also DLLs referenced by your project need to be WinRT DLLs built specially for WinRT.
I'm trying to deploy some sort of framework and therefore need to register some assemblies in the GAC.
The interesting part is:
These GAC assemblies should only be used by the framework developer, the client apps should not use these GAC assemblies but the ones in their local directories (the GAC assemblies could be of a different version, most likely higher).
I've already found and tried the app.config setting but it seems to be ignored by the client app (latest .NET runtime installed is 3.5).
Because you will be loading two different versions of a given dll in the memory you need to isolate them. common methods are;
Creating an AppDomain. You create two dll's. The first dll creates a new AppDomain from your code and then loads the second dll which is linked to those dependencies.
Use a service process. You create one dll and a service application. The dll starts the service application in a new process and connects using for e.g. remoting. The service application is linked to the components you need to bind to.