I wrote a web service (c#, VS2012, windows7 64bit), which calls a COM dll.
Using visual studio, there was no problem to execute the web service and thus the client's application.
After trying to locate the web service in the IIS, all calls to the COM dll's function failed.
What could be the problem? Is there any specific configuration of the IIS for COM dlls?
Try to change the executing user of the app pool to a custom account instead of a built-in account. Try to run it as an administrator first and get it to work. Then try with a more restricted user account.
I changed Framework version from 3.5 to 4. then sloved.
ref: http://quickstartprojects.org/2011/11/webservicesindotnet4/
Related
I have a classic ASP application that uses a custom written VB6 COM object (.dll) through Server.CreateObject.
I can deploy and run classic ASP (.asp) in an Azure web app, but I'm not sure how to get to the point where I can use my VB6 COM object.
Uploading the .dll to the web folder and using Server.CreateObject just results in the expected:
An error occurred on the server when processing the URL. Please contact the system administrator.
If you are the system administrator please click here to find out more about this error.
Is it possible to use your own custom .dlls?
That's not possible using Web Apps. Using Virtual Machines, you have more control and you'll be able to register your COM DLL.
My application can not deploy because of the following error:
Web deployment task failed. (The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.)
Right now, I'm attempting to deploy my .NET application to IIS. VS is attempting to target the "DefaultAppPool" application pool. I want it to instead target the "ASP .NET v4.0" application pool. How do I do that in Visual Studio?
I am trying to not change any settings within IIS if possible.
I don't know if this would be considered a hack, but it got the job done without any issues.
What I did was I first created a folder in IIS and then converted it to an application. After which, I had it target the .NET 4.0 application pool and voila, Visual Studio was able to deploy the application without the error.
I hope this helps people in the future that Google their issue and come upon my question.
I have a ASP Net project of the type Windows Service.
When I build that project an exe file is generated.
Now I also have another project os the type Web Service, that uses classes from the previous Windows Service project.
When I build the Web Service, on it's bin/debug folder, the Windows Service exe is there, instead of a DLL.
This way, when I deploy the Web Service on ISS, I get an exception when the part of the code that instatiates a class on the Windows Service project is executed.
The only whay I found to solve this issue, is to make the output type of the Windows Service to DLL instead of EXE, and the Web Service runs correctly.
But, of course, when I try to install the Windows Service, I get this error:
Can I even do this?
Windows Services and web services are different project types. You cannot run the same executable. You have to options:
Either you put the common code into a class library and create a project for the windows service and one for the webservice
You create to build targets.
Option 1 seems to be easier for me
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.
I have created a reference to an IIS hosted WCF service in my ASP.NET website project on my local workstation through the "Add Service Reference" option in Visual Studio 2008. I was able to execute the service from my local workstation.
When I move the ASP.NET web site using the "Copy Web Site" feature in Visual Studio 2008 to the development server and browse to the page consuming the service, I get the following error:
Reference.svcmap: Specified argument
was out of the range of valid values.
Has anyone experienced this same error and know how to resolve it?
EDIT: My development server is Win2k3 with IIS 6
The problem may be due to a mismatch with the solution/project folder structure and the IIS web site folder structure. I ran into similar problems a good while ago and ended up changing how I deploy web services. Here and here are some discussions of similar problems to yours, they ended up not using the Add Service generated client and rolled their own client. Also, I can vouch for using the "Publish web site" method for deploying my services. Here is a good article on web service deployment models.
#Sixto Saez: I was able to use the following resource similar to the one you provided to generate a proxy class using the ServiceModel Metadata Utility Tool (svcutil.exe).
Here is the exact command line:
svcutil /t:code http://<service_url> /out:<file_name>.cs /config:<file_name>.config
Here is the reference I found that suggested using the method.
Also, I was able to consume the service by creating a reference using the Visual Studio 2008 "Add Web Reference" command. It generates code based on .NET Framework 2.0 Web Services technology.
Unforunately, the WCF service web site and I can not use the svcutil solution (Unless you know of a way how...). Do you deploy you service or your web site with the service reference using Visual Studio 2008 publish web site feature?