I am working on a project that was last worked on by someone who hasn't been on the team in some time. Having gotten a hold of him to ask him questions about the project and next steps in general, I was told I need to run a Java web service. After not being able to find any .jws files in our network, I asked if a particular .svc (WCF Web Service) file was the right service and was told to "run [filename]" which is the .svc file. This file is in a directory with some relevant Java class files that appear to have been part of an eclipse project (which I am unable to open).
Now I've looked around and all tutorials I can find about running a .svc file involve a visual studio project and creating the project from scratch, not just running a single .svc file as a web service. I'm new to Windows in general and haven't seen a .svc file. Does it make since to say to simply "run" a .svc WCF Web Service? And does it make since that a .svc file would be created from a Java project? If so, how would I simply run that service?
I hope this question made sense. Thanks for any help!
Related
The following errors pop in the log when publishing web project to folder.
....
Publishing folder /...
Publishing folder bin...
Publishing folder bin/es...
Publishing folder bin/roslyn...
Unable to add 'bin/roslyn/System.IO.FileSystem.dll' to the Web site. Unable to add file 'bin\roslyn\System.IO.FileSystem.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/System.IO.FileSystem.Primitives.dll' to the Web site. Unable to add file 'bin\roslyn\System.IO.FileSystem.Primitives.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/System.Reflection.Metadata.dll' to the Web site. Unable to add file 'bin\roslyn\System.Reflection.Metadata.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/System.Security.Cryptography.Algorithms.dll' to the Web site. Unable to add file 'bin\roslyn\System.Security.Cryptography.Algorithms.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/System.Security.Cryptography.Primitives.dll' to the Web site. Unable to add file 'bin\roslyn\System.Security.Cryptography.Primitives.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/System.ValueTuple.dll' to the Web site. Unable to add file 'bin\roslyn\System.ValueTuple.dll'. The process cannot access the file because it is being used by another process.
Unable to add 'bin/roslyn/VBCSCompiler.exe' to the Web site. Unable to add file 'bin\roslyn\VBCSCompiler.exe'. The process cannot access the file because it is being used by another process.
Publishing folder bin/zh...
...
Publishing folder Views/WFDefs...
Publish failed. Target file://machine/d$/PATH.
If i publish using web publish it works, but the real target doesn't support web publishing.
Note: VBCSCompiler is not running.
I had the same problem with my application with Visual Studio community 2017. In my case the solution was simple, I only deleted all the files inside the directory bin (C:\Projects\DotNet\ApplicationName\bin) and after I recompiled the application.
I hope it can help you.
Had this same issue in Visual Studio 2017 Community Edition. As your question came up in Google but no answer, I thought I'd add to it.
I found Process Explorer from Sysinternals helped me a bunch.
Open sysinternals and go to Find -> Find Handle or DLL... or (Ctrl + F) and search the file that's being held open. In my case "System.IO.FileSystem.dll"
The search results showed two instances of MSBuild and one VBCSCompiler was hanging onto the files. Worst case, I just killed the process tree, built the project and all was well again.
Related answer: https://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows
If you try to publish asp.net web app in Azure and getting above error then try to UPDATE the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package to V1.0.7 or later. Initially, in your application, there will be Microsoft.CodeDom.Providers.DotNetCompilerPlatform version 1.0.5 then uninstall and then install the latest version V 1.0.7 or later of it. Clean your solution and build. Now you will be able to publish your web app in Azure using Visual Studio 2017.
No matter what I change in an asmx service in Visual Studio, the WSDL file stays always the same. Deleting methods, changing method signatures don't have any effect when I browse to service definition.
I have had a simular problem.
When removing an enum and replacing it by a string, the enum wouldn't go away from the wsdl. No matter what I tried (clean, rebuild, clear browser cache, other browser), it kept returning the enum as a complex type within the WSDL.
The solution in my case was remove the local folders of the project via windows explorer, then perform a get latest from TFS. After this the problem was solved.
Of course this solution only aplies when using a sourcecontrol system.
After changing your service, you must build it and ensure that the new version is running. One shortcut would be to build it (and make sure there are no errors), then right-click the .ASMX file and choose "View in Browser".
Also, although I'm sure you're aware of it, you should not be using ASMX web services for new development. Microsoft now considers ASMX to be a legacy technology. Use WCF instead.
I have encountered this problem and have a solution.
Cause: When you create a new "Web Service" project in Visual Studio, it automatically adds a "Service1.asmx" file to your project. You rename this file and change the class declaration inside of it, but Studio still thinks it's "Service1" wnd will only ever display the web service definition for "Service1".
Solution:
Delete all "bin" and "obj" folders in your project.
Copy the methods from your existing asmx file to notepad.
Remove the service from your project.
Add a new service to your project, with the name you want.
Paste the code from Notepad into the new service.
Rebuild All
Your asmx should now accurately reflect your web service and update normally on future builds.
I had today the very same issue. It was caused by a GACed version of the assembly that contained the type definitions exposed by the web service. I had to remove the assembly from the Global Assembly Cache first, like:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u YourAssemblyNameWithouthDllExtebsion /f
Be sure to restart the web server hosting the web service to reload the new version of the assembly, for example, in case of IIS Express, you can kill the former process instance by PowerShell:
(Get-Process -Name iisexpress).Kill()
After that, the updated WSDL version was displayed as expected.
I have written a WCF web service in C#. I had originally self-hosted it and then decided to host it on IIS running locally on my PC. While the service is working, there are several aspects of the deployment process that I don't understand:
Firstly, the URL of this service when hosted in IIS does not correspond to what I specified in my web.config. I had specified "http://localhost:8000/MyServices/OrderService" there and this was used when I self-hosted. Now that I've deployed to IIS, the URL has become "http://localhost/MyServices/OrderService". Why is the URL not picked up from my config file?
Secondly, to host the Web Service, I created a new web site within IIS (in addition to the existing 'Default Web Site'). I set the physical path to c:\inetpub\wwwroot (no idea if this is correct) and left the other parameters as default. I then copied my /bin folder, my .svc file and my web.config to this folder. Is this the equivalent of a 'Virtual Directory'?
Finally, the service didn't work until (within IIS) I selected 'Convert to application'. Why is it necessary to select 'Convert to application'?
Can anyone explain what the correct procedure is to publish a simple web service from Visual Studio into IIS, or point me at some good documentation so I can understand the process?
****EDIT TO ORIGINAL*****
Having spent more time looking into this, I have found the following:
When I create a web site in IIS, I give it a physical directory of c:\inetpub\wwwroot....etc
If I then "publish" from within Visual studio, all it's doing is copying all the required filed (like the /bin directory, web.config and .svc file) into the physical directory of the website i.e. - c:\inetpub\wwwroot...
You can perform the copy manually to the same affect.
Lastly, with regard to the URL of my service not corresponding to the baseAddress section of my web.config file, this has been answered on stackoverflow previously.
The answer is that the baseAddress is completely ignored when hosting on IIS.
If using Visual Studio 2010 you can right-click on the project for the service, and select properties. Then select the Web tab. Under the Servers section you can configure the URL. There is also a button to create the virtual directory.
I deployed a web service to iis 7, it was working all the way right.
Then I wanted to update the code of a web method in the web service.
I recompiled the service and updated the dll in the iis directory with the new one.
My problem is when I invoke the service, it invokes the older code.
I tried changing the number of parameters passed to a web method inside the service, and when invoking it still sees the older parameters which I erased.
Web services after Framework 2.0, are compiled as DLL files by default as far as I know. Normally, this happens when you PUBLISH the website and webservice, or when you use Web Applications.. But in WebServices, Visual Studio compiles the output as DLL. Therefore, you should compile your dll and update on the IIS. Even though you see the CS code files on IIS folder, they are not being used. Only the asmx file (not asmx.cs) are used to map the code in the dll.
I am guessing that the old code is cached. Try restarting IIS. That should cleanup any remnants of the old code.
It seems that you need to update your service reference.
Go to the project who's using the service, left-click the service reference in your solution explorer and finally choose "Update Service Reference".
Maybe I'm wrong and you did it, but as you don't mention that in your question, this is my suggestion.
rebuild the solution, And deploy the service on IIS. It will work definitily
I develop a Webservice using Netbeans 6.9 and I use an embedded glassfish server to deploy my Webservice (http://some_domain/project_name/ws_for_sl4). On a different server there is deployed a Silverlight 4 client, which should have accesss to the Webservice.
I know that I have to have clientaccesspolicy.xml (under http://some_domain/project_name) however I do not know how to do it. I mean, I do not know in which folder of the netbeans project I need to put clientaccesspolicy.xml to have it automaticly deployed on an embedded glassfish server. To have my SL4 client using the webservice.
Solution:
- put clientaccesspolity.xml and crossdomain.xml under /Web Pages*
- open Project Properties (click right mouse button on a project root), go to Run, and delete a value of "Context Path".
Now your WS will be deployed directly under some_domain as it is required by SL4 (SL4 is looking for these files under the domain name.). SL4 will have no problem to access clientaccesspolity.xml and crossdomain.xml.
In case anyone doesn't like moving their webservice to "root", and instead prefers to have it in http://localhost:8080/aDifferentLocation/MyActualWebService, then placing those XMLs in the project Web Pages folder doesn't cut it.
http://localhost:8080/aDifferentLocation/clientaccesspolicy.xml
and
http://localhost:8080/aDifferentLocation/crossdomain.xml
would not work, as they need to be in
http://localhost:8080/clientaccesspolicy.xml
and
http://localhost:8080/crossdomain.xml
To achieve this, you must track down the folder where your GlassFish server is installed, let's call it [GlassFishInstallPATH] and paste the XMLs into the subfolder called docroot:
[GlassFishInstallPATH]/domains/domain1/docroot/ <--here go the XMLs.
(source)
In case you're wondering how you would do the same thing in Eclipse, you must track down the ROOT folder in your Eclipse J2EE workspace:
C:\Eclipse_j2ee_workspaces\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\ROOT/ <-- the XMLs go here.