We are creating a WCF service with a companion client DLL (.Net) that we will be delivering to a user's GAC via a web page. The DLL knows how to communicate with and how to interface with the service, and will allow the web page to communicate with the WCF service via client-side Javascript calls. The user's machine will be executing the DLL's functionality, not the server. With it data will be transferred to the target server.
This works in theory (and practice) over our internal network. The network is, of course, in a trusted zone so there are no problems with delivery, GAC install and DLL utility. The client-server pair works as expected. We can download the .Net DLL with an object tag, install it in the GAC and use it easilly.
In order for an internet user to be able to download the client .Net DLL however there are security procedures that need to be put in place. We do not have the expertise yet to know exactly what they are, but we are aware that we will need to at least sign the DLL with a trusted certificate. Beyond that, we are unsure.
The question then is what do we do from here?
Give the assembly a strong name (sn.exe - etc)
Create a Windows Installer Project from Visual Studio that will add your custom assembly to the target machine's GAC. (Right click File System on Target Machine | Add Special Folder | Global Assembly Cache folder). Let users download your installer from your web page, probably the most painless way instead of forcing something via the browser.
Related
I am building a client-server application, this is all running locally on my computer whilst I am developing the system. However, eventually I would like to deploy the server-side part of the application to a server to run 24/7, enabling client applications to connect and consume the service at will. What I would like to know is, when I come to doing this would I simply just install the server-side application on the server, hit run and that's it? That just seems... well not right (to me), is this the way it is done? or is there a lot more to it? I imagine there is, but I can't seem to find any content on this subject.
FYI - the server is a self hosted WCF application.
You'd want to take your program's executable, support dlls and config files and drop them into a folder. Then create a Windows Service to run the program; if you don't use a Windows Service, the program will only run while you're logged on, which isn't good. As a Windows Service, a reboot of the server will bring the program back online even if you're not logged on.
Here's a knowledge base article from MS on how to make a windows service.
http://support.microsoft.com/kb/251192
If you're program is compiled as a DLL, then create a small .exe program to run it (a wrapper) then deploy the program as described in the article.
Good luck.
Short question:
Does the Windows Store allow applications that obtain DLLs or other low-level resources not packaged at compile time? Is there a requirement either by Windows Phone or Microsoft that requires DLLs to be signed? If so, can I use a DLL in my application that is signed by another developer?
Why I'm asking/explanation:
I'm working an an application for Android that allows users to download extensions (like themes), and I'd like to port this to Windows Phone.
I have determined that it's not possible for my app to utilize libraries or other resources of other applications downloaded from the Windows Store. (Please correct me if this is not always the case)
The workaround I'm considering is an in-app download center for other resources specific to this application. I'm wondering if a downloads for this app, specifically DLLs, can be used in my application. These DLLs would be developed by 3rd party developers, so I see that signing might be an issue.
The store specifically prohibits any additions / modifications after the app has been purchased. So although it may technically be possible, they won't certify it.
This makes sense if you think about certification . If they would allow this, it would make certification a moot point, since you would just publish a basic app, and afterwards side-load the uncertified part.
I have a vb6-mysql client-server desktop application which is distributed as a setup file.
It uses DLL all logical operations as well as database operations. The EXE and the DLL are installed in the server as well as the client machines. When I say server which only means the database resides in that machine no other difference in EXE or DLLs.
As all the database operations are done in the DLL when connected from a client machine, performance would be less. It is not possible now to change all the logic into database.
Is it possible to store the DLL in the server machine only and use the same DLL by the client machine also so that database connection will always be from the server itself?
Is converting the DLL to a windows service the possible solution for this?
How can I to convert it to a service?
And finally, if it is possible to make the DLL act as a service, what would the connection issues be?
You appear to be trying to rediscover n-tier application development.
The usual way this would be done using VB6 within a LAN would be to create an ActiveX EXE instead of a DLL so you can use DCOM. However DCOM isn't something you'd want to expose over the Internet.
For such cases it is more typical to use a commonly-open-port protocol such as HTTP or HTTPS. Almost everyone has firewall settings permitting outbound HTTP and HTTPS connections and most of the major Web servers undergo regular hardening to make them safer to expose to the Internet.
The classic way to do this with VB6 was to use IIS to host the Remote Data Service, which uses a form of Web Service "under the covers" where your program doesn't deal with the gory details. However this is a deprecated approach, and today configuring IIS and the RDS components can be a chore since they are locked down hard by default.
This leaves you with such things as the deprecated SOAP Toolkit or 3rd party tools such as those in the PocketSOAP suite... or you can roll your own.
Doing this from scratch can be a bit of work but is more flexible, allowing REST instead of SOAP which can have advantages in itself. You could use whatever Web server you choose that can work with VB6 (via CGI, etc.).
The hardest approach to justify might seem the simplest on the surface: create your own protocol over TCP and write a Windows Service. This can be the most flexible of all but it can be more work than other options and you are on your own as far as making it and keeping it secure. You'll probably also face firewall issues depending on where your clients are and what the local firewall policies are there.
When we could rely on DCOM the issues were relatively small aside from security configuration headaches. With the Internet in the picture it is an entirely different story.
This really isn't something you undertake casually. Even assuming that your database is safe exposed to the Internet is naive and should be rethought.
We have a WCF service hosted in IIS that currently calls a VB6 DLL to do part of its job. This works fine, but we can't deploy the service to a 64-bit target environment without configuring IIS to run it in a 32-bit worker process.
I am currently investigating ways around that restriction. Porting the VB6 DLL to .NET is not possible for various reasons, so I created an ActiveX EXE wrapper around the DLL in VB6, so that the service can run in 64-bit and the VB6 parts in 32-bit.
When I tested the service I got this error:
Type: System.UnauthorizedAccessException
Message: Retrieving the COM class factory for component with CLSID {9AE7303B-D159-43F6-B1A5-52D297581820} failed due to the following error: 80070005.
After some Googling I found that this is due to either:
Calling an MS Office component
DCOM permissions not being configured
NTFS file permissions not allowing read/exec access to the IIS worker process identity (ASPNET in my environment)
Of these:
Definitely not applicable
Also not applicable; I am not hosting the EXE in DCOM or COM+, just a simple COM out-of-process activation
This looks likely; however, I checked the permissions, and NTFS reports that the Users group (which ASPNET is a member of) does indeed have read/exec access to the file
I tried calling the EXE from a unit test fixture, which is executed in my admin-level account rather than the IIS worker process account, and it worked fine, so the error is definitely something to do with permissions. I'm not sure what to do next. Can anyone suggest things I can check?
My test environment is Windows XP / IIS 5.1
UPDATE:
The IIS virtual directory is configured for Anonymous+Windows access; the WCF service uses only Anonymous authentication, the Windows authentication is for the VS debugger. Task Manager reports that the aspnet_wp.exe process is definitely running in the ASPNET account.
I explicitly granted Read and Execute access to the ASPNET and IUSR_<machine> accounts on all the COM exes and dlls involved. This made no difference.
I explicitly granted Local Launch and Local Activation access to the ASPNET and IUSR_<machine> accounts on the relevant interfaces in the DCOM configuration. This made no difference either.
As I see it I have 3 options:
Keep trying to get this working somehow.
Go the whole hog and host the EXE in COM+.
Give up. Tell users that the WCF service must be configured to run in a 32-bit app pool on 64-bit Windows.
Your error is an Unauthorized access exception. Therefore, the problem is probably rights related.
You could check what the security context of the 32bit worker process is.
Also check your event log, they may be information there about what account is being used.
I have a UI hosted on a webpage. I'm able to run the control on the server hosting it, but when I attempt to run it from other machines on the intranet, only some of the required DLLs make it to the client.
What direction can I take to investigate why this is happening?
I don't think an ActiveX control copies DLL's to the client. More likely the clients already had some of the DLLs. You'll need to install the additional DLLs somehow (as a downloadable installer or using custom code). You may run into permissions issues trying to install DLLs via a web page.