have been given a URL to a WSDL, a piece of it is here..not sure if this is a pertinent piece or not. I know how to add the web reference and import the namespace in Visual Studio 2005.
Questions...how do I pass my values to it? How do I encode for binary-64? I have the methodname (GETP)...not sure how to invoke it as a function to pass parameters, or if that is even the correct way to do it with this type of reference. Have only consumed .asmx files previously.
<wsdl:message name="GETPResponse">
<wsdl:part name="GETPReturn" type="xsd:string" />
</wsdl:message>
<wsdl:message name="GETPRequest">
<wsdl:part name="BASE64DATA" type="xsd:base64Binary" />
</wsdl:message>
<wsdl:portType name="Dist">
<wsdl:operation name="GETP" parameterOrder="BASE64DATA">
<wsdl:input message="impl:GETPRequest" name="GETPRequest" />
<wsdl:output message="impl:GETPResponse" name="GETPResponse" />
</wsdl:operation>
</wsdl:portType>
Just use "Add Service Refrence" and point it to the WSDL. See "How to Consume a Web Service".
This site has how to create a WSDL class and use that, or how to reference the web service using a Visual Studio web reference: https://msdn.microsoft.com/en-us/library/ms155134.aspx
Neither option worked for me. I needed to create the WSDL class like at that site, but the web reference didn't work for me, and neither did just adding that class to my App_Code folder and trying to instantiate it. So I opted to create an assembly out of the WSDL class, then reference that assembly in my project. This was the only way I could get any useful classes/methods available to me. Here are my general steps, from start to finish, that worked for me.
Ensure you have the right URL at the top in your ASMX.cs file of your web service: [WebService(Namespace = "http://localhost:99999/WebService1.asmx")]
Leaving that as the default "tempuri.org" will cause you unbearable grief.
Get the Windows SDK for your workstation/server & install.
On a command line, navigate to WSDL, which for me on Server 2012 was: cd C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
Then, use this: wsdl /l:CS /protocol:SOAP http://localhost:99999/WebService1.asmx?wsdl
You can then do one of 2 things:
The proxy class will be generated in that same folder where you navigated on the command line. Go to it in Explorer, copy it into a
new Class Library Visual Studio project, at the root of the
solution. (For details, go to
https://msdn.microsoft.com/en-us/library/cc175801(v=vs.90).aspx and
skip to "Creating a Project for the Proxy Assembly".) Sign the
assembly (details on that same site, section "Signing and Building
the Proxy Assembly"). (I didn't bother with the serialization
exceptions or struct stuff - just those 2 sections, only.)
-OR- (easier)
Just use CSC to build your assembly:
Move your proxy class to the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder.
Launch a command line and cd to that folder.
Run this command:
csc /t:library MyWebServiceProxyClassFile.cs /reference:System.Web.Services.dll /optimize
Obviously, replace "MyWebServiceProxyClassFile" with the name of your proxy class file. It will give you a DLL file with the same name as your proxy class.
Import the assembly in your client project by going to Add Reference and browsing to the assembly in that proxy project you just built in step 4. It should be in the MyServiceProxy\bin\Debug folder. (Or browse to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 if you left it there, from using CSC.)
Instantiate using the class name of your web service:
YourClass service = new YourClass();
You should see the webmethods available when you do service. with intellisense.
You'll likely need to add these parameters:
service.Url = "http://localhost:99999/WebService1.asmx";
service.Credentials = CredentialCache.DefaultCredentials;
(Add using System.Net; to the top of your class to use that last one.)
For those saying this is the "old" or "obsolete" way of doing it, I say this worked for me, and would say to tell Microsoft to make it work using the web reference and we wouldn't have to do it this way. Besides, this is largely their documented process, after all, with some of my own findings put in. And I noticed something else - svcutil generates a totally different, WCF-compliant proxy class, which WSDL does not, so be careful what utility you are actually using - they are NOT created equal.
Also, I made my own batch file for creating a proxy class from a web service, then building an assembly from it using CSC, like I have above:
echo off
cls
cls
set /P svc="Input the URL to your web service's Service.asmx file: "
cd \
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
wsdl /l:CS /protocol:SOAP %svc%?WSDL
set /P name="Type the name of the service's class' name (no .cs on end): "
move %name%.cs C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\%name%.cs
cd \
cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
csc /t:library %name%.cs /reference:System.Web.Services.dll /optimize
move %name%.dll C:\%name%.dll
move %name%.cs C:\%name%.cs
echo Your DLL and Proxy Class are waiting for you at
echo.
echo C:\%name%.dll
echo.
echo. and
echo.
echo. C:\%name%.cs
echo.
explorer.exe C:\
pause
cls
exit
This is set up to run on Server 2012 with the Windows SDK installed. You could run it on any platform if you change the place wsdl is found to point to Visual Studio's SDK folder, if you install that, ex:
cd "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin"
instead of that NETFX Tools folder.
You would use it by first entering the URL of the web service, ex.
http://localhost:99999/WebService1.asmx
When the class is generated, you give this program the name of the class file, minus the .cs. It should also be the same as the default class name at the top of WebService1.asmx.cs, in my example.
It will then leave the proxy class and assembly file at the root of C: for you.
For those wishing to pursue converting the ASMX into a WCF interface, I found this: https://msdn.microsoft.com/en-us/library/vstudio/ms751529%28v=VS.100%29.aspx
that looked promising, which has you use svcutil to produce the proxy, I'm assuming add it to an ASP.NET App_Code folder (it doesn't say) and add a service reference to the ASMX web service URL, but not a lot of detail/guidance on how to name the contract and where to put that <client> snippet in the web.config, though I believe it goes in <system.ServiceModel>.
Related
I just installed VS 2013, upgrading from VS 2010. Creating a web deployment package zip file used to work in 2010. using VS 2013's Publish Web feature to publish to a Web Deploy Package, I getting the following error:
Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The details in the Web Publish Activity tab shows the following:
Transformed Web.config using D:\dev\DMWeb\DMWebClient\Web.Test.config
into obj\Test\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Views\Web.config into
obj\Test\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Test\TransformWebConfig\transformed\Web.config into
obj\Test\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish: obj\Test\Package\PackageTmp.
Packaging into D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.zip.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(3883,5):
Error ERROR_EXCEPTION_WHILE_CREATING_OBJECT: Web deployment task failed. (Object of type 'manifest' and path
'D:\dev\DMWeb\DMWebClient\obj\Test\Package\DMWebClient.SourceManifest.xml' cannot be created.
Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Package failed.
In VS 2010, I've had to run it as Administrator for deploy to work, and I'm doing so here as well. I've also tried giving Full Control permissions to the project folder to NETWORK SERVICE, LOCAL SERVICE, Authenticated Users, and myself.
In the Package folder, there is the PackageTmp folder (which looks good), and the DMWebClient.SourceManifest.xml file, and that's it. In VS 2010, there's more files there.
DMWebClient.SourceManifest.xml contains:
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<IisApp path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp\App_Data" setAclResourceType="Directory" setAclAccess="Write" />
<setAcl path="D:\dev\DMWeb\DMWebClient\obj\Test\Package\PackageTmp/DMWeb.config" setAclResourceType="File" setAclAccess="Read,Write" />
</sitemanifest>
In VS 2010, the last line containing DMWeb.config doesn't exist. On top of that, the path to it is wrong. It should be under the App_Data folder.
DMWeb.config is specified in Web.config like this:
<appSettings file="DMWeb.config">
Any help would be greatly appreciated.
This can also happen if there are any files in your project that have been moved, deleted, or renamed from the file system such that Visual Studio doesn't know where to find them.
My error was allmost identical:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
(3883): Web deployment task failed. (Object of type 'manifest' and
path
'D:\B\280\Binaries_PublishedWebsites\ProjectName\ProjectName.SourceManifest.xml'
cannot be created. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
The reason I found out is in the ProjectName.SourceManifest.xml file.
There is a line: <appHostConfig path="Default Web Site/ProjectName" />
If this webapp and site does NOT exist on the buildmachine, the error occurs. Once I created a dummy webapp site with the same name on the same site, it built!
And solved by removing that section with MsBuild parameters: /p:IncludeIisSettings=false /p:IncludeAppPool=false (i had those 2 to true, so only applies when you have them true)
Found out that I had an old .wpp.targets file from VS 2010, it was called ~DMWebClient.wpp.targets. In VS 2010, by renaming it, it would ignore it and not apply it. It seems like VS 2013 applies any .wpp.targets files regardless of the file name.
By removing that file, web deploy works again.
Thought I would add as none of the other answers fixed my problem, though perhaps more related to Lightswitch Web Deploy than ASP.NET Web Deploy (though OP doesn't specify which).
There are three projects within a standard Lightswitch Template solution. Two of them might be named lightswitchapp.HTMLClient and lightswitchapp.Server. Neither of these should be deployed! You should deploy the third project lightswitchapp.
I had been getting errors like this, which led me to this page.
Web deployment task failed. (Object of type 'manifest' and path 'manifest xml hidden' cannot be created. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXCEPTION_WHILE_CREATING_OBJECT.)
Great answer above, regarding the Lightswitch Web Deploy...couldn't find anything about it anywhere...kept thinking MS broke this on purpose because they don't want to support LightSwitch anymore...
In any case, once you go through the steps on publishing the main project from the LightSwitch template, a new problem arises, regarding the publish params if you push to a local IIS.
For all of you struggling with that...first install
httpPlatformHandler_amd64.msi
WebDeploy_amd64_en-US.msi
then, make sure "Web Deployment Agent Service" is running as a service
then, in Visual Studio (I am on VS2015 community), on the Publish Settings tab in the wizard, make sure you have something like this:
Service URL:
http://localhost/MSDEPLOYAGENTSERVICE
Site/Application:
Default Web Site\trax01
where trax01 is the name of your web app that runs under Default Web Site (please notice the back-slash before "trax01" compared to the forward-slash in the label for the setting.
Hope it helps somebody else, because this thing ate my liver! :)
The same exception can still happen in Visual Studio 2019. Additional detail for me was Object of type 'manifest' and path 'manifest xml hidden' cannot be created.
In my case the problem was a MsDeployDeclareParameters item in the {ProjectName}.wpp.targets file. It was attempting to set ACL permissions for the downloads folder, but the folder didn't contain any files so it wasn't present in the staging area.
Adding a file to the downloads folder resolved the problem (as would removing the MsDeployDeclareParameters entry from the {ProjectName}.wpp.targets file).
I tried many Solution by updating security to TLS 1.2 (X)
Removed * or special character from variables and password.
But later I found that, we have * in the password of connectionString in web.config.
I changed my password and it started working for me.
I have an ASP.NET web application written in C# 4.0. The application references a class library that comes with its own configuration file. At runtime, the class library uses similar to the following code to load this specific configuration:
var exeConfigPath = this.GetType().Assembly.Location;
var config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
This is done because the library has to load its bundled configuration rather than the application configuration. The application configuration should not be concerned of the library's settings and should not be able to alter them.
Now, there are a few other things that need to be done for this concept to work. I have to set the library's configuration file build operation as Content in the properties window and the Copy to be Copy Always or Copy If Newer. So far so good - the file gets automatically both into the class library's bin directory, and the web applications's bin directory, and is correctly renamed from App.config to CustomLibrary.dll.config (as supposed, the library's dll is CustomLibrary.dll).
Now I am facing two issues.
1) When I publish the web application to a filesystem location (mapped in IIS), the CustomLibrary.dll.config appears back as App.config in the bin folder of the published app. OK - I will rename it in the class library project to match the expected convention - and problem solved.
2) Even when published, the IIS compiles the application again and stores it in the ASP.NET Temporary Files. There is a fancy directory structure with a folder dedicated for each assembly referenced. The folder corresponding to the CustomLibrary.dll does not contain the config file in it. Since this.GetType().Assembly.Location will return the path to the temp folder, the application fails to load the configuration and crashes as it should.
I need to preserve the pattern of having the configuration in the class library, and be able to make it work in the web application. When manually copying the .config to the temp folder, the app works, but see, I really hate manual copying to randomly-named folders.
Is there a way to either prevent IIS from using the temp folders, or to make it copy along the config files? I believe the problem I am facing is configuration-related rather than conceptual since the application works as expected when the config file is in place. I'd prefer not to mess with using hard-coded physical paths to the config file either.
Edit:
To make it clearer, I will point out what and why I want to achieve. The idea is that the library and the web project will be developed as separate products - there will be no user or application specific information in the configuration of the library, so it will not change for different use scenarios. It is also rather specific to the class library functionality rather than the end application. It makes sense for me to keep the library's configuration information bundled within it (similar to Java, where a spring context xml file, or a properties file, get bundled with the jar of the library). I'd like to avoid having to copy the configuration in each app/web config of the consumer application. There will be cases where the consumer application is developed by third parties, and I do not want to rely on them doing their configuration right for my stuff to work. Again, the only issue here is not having the config file copied to the right place.
If those are static, internal settings that nobody should see or change, wouldn't you be better off having a file with the configuration included within the class library as an embedded resource? Either that or just a static class with the settings.
That way you'd be certain that nobody alters it, which in your scenario seems to be a plus.
I have come along a way to work arround the described issue, still not a very pleasant one to my requirements.
The solution is to take advantage of the application configuration (web.config in web apps, or app.config) which is always available. I have added as settings the absolute paths to the config file for each library. So I ended up with:
<!--
THIS IS IN THE WEB.CONFIG FILE
-->
<appSettings>
<add key ="ClassLibrary_ConfigPath"
value ="{My Publish Output Folder}\ClassLibrary.dll.config"/>
</appSettings>
and the class library now uses the following code to load its configuration:
Configuration config = null;
try
{
var exeConfigPath = this.GetType().Assembly.Location;
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
catch (Exception e)
{
if (!IsConfigurationNotFoundError(e))
{
// IsConfigurationNotFoundError logic skipped for brevity
var exeConfigPath =
ConfigurationManager.AppSettings["ClassLibrary_ConfigPath"];
if (exeConfigPath != null)
{
config = ConfigurationManager.OpenExeConfiguration(exeConfigPath);
}
}
else
{
throw;
}
}
While this works, I will wait for a better solution if possible. Still, I do not have to copy the entire ClassLibrary.dll.config into the web.config file, but now I must manage filesystem locations and be aware of app-setting names. What I really want is the consumer app of the ClassLibrary.dll not to deal with its configuration in any way. If it were a desktop app, I have this covered, as Visual Studio copies the ClassLibary.dll.config appropriately. I hope there is a way to make it work smoothly for web apps.
The short answer is: you can't. You have to merge both configuration sections and place all settings in the main configuration file of your application. In case of the web application it would be the web.config. Read this
I have inhherited a vs2010 c# web project (asp.net). It has a web reference to a web service. There's been a slight change to the service - a new operation has been added. I'd like to update the proxy class so that i can call the new operation but i can't find the class. I seem to remember there used to be a "show all files" button in solution explorer that would reveal the proxy class but i can see no sign of that. Unfortunately, i'm not able to refresh the proxy by pointing it at the web service metadata wsdl because vs is no longer installed on any pc that can reach the web service. Anyone know where i can find the proxy class?
It doesn't matter you can't find it in Visual Studio - you can always locate a proper file in your filesystem, under the project directory.
Problem was, the app was running - doh!
Yes, you are right. There is a "Show all files" icon in the tool bar. It will only be available when you have a project selected, so you want to select the web service's parent project:
Expand the service reference and under it the file called Reference.cs is the proxy class.
You should NOT be hand editing this though. You should make the changes to the service and then regenerate the proxy using the Update Service Reference right click option. But then if you really can't do that as you say, then just hand edit the file. But beware that any changes you make will be lost if someone does regenerate it again in the future. Very Risky! (I prey you are using source control)
There is a WSDL.exe command line tool.
Copy and execute this command line tool in the PC where you can have access to the WebService, it will generates the proxy again and you can replace them with the files in your project.
http://msdn.microsoft.com/en-us/library/7h3ystb6(v=vs.80).aspx
This is maybe a really simple question, but I couldn't locate an answer:
For a client I need to HOST a webservice. The client has sent me a wsdl file that the webservice should 'implement'. How do I go about that? I've generated any number of client-rpoxies but this is the other way around. I can use both ASP.NET 2.0 webservices or Windows Communication Foundation.
wsdl.exe /server.
Generates an abstract class for an XML
Web service based on the contracts.
The default is to generate client
proxy classes. When using the
/parameters option, this value is a
element that contains
"server".
You can do a similar thing with svcutil.exe for WCF- something like:
svcutil.exe thewsdl.wsdl /language:c# /out:ITheInterface.cs (I've not tested this).
Edit- John Saunders makes a good point in his answer to favour the WCF approach- I recommend this too.
Actually, you should do this with svcutil.exe, not with wsdl.exe. WSDL.EXE is part of the ASMX web service technology that Microsoft now considers to be "legacy" code, which will not have bugs fixed.
You can do plenty with that WSDL (wissd'le) file.
From doing the WS Class manually to use the Auto Generated class from wsdl.exe
let's imagine that, for your example, you have this WDSL (tooked from WebServiceX.Net)
to create a C# auto generated proxy you go to your command prompt and write:
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts http://www.webservicex.net/TranslateService.asmx?wsdl
Note: inside your C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin folder you will find wsdl.exe or just do a dir /s inside your C:\Program Files\
if you want in Visual Basic, just use /language:vb or /l:vb
/language:
The language to use for the generated proxy class. Choose from 'CS',
'VB', 'JS', 'VJS', 'CPP' or provide a fully-qualified name for a class implementing System.CodeDom.Compiler.CodeDomProvider.
The default
language is 'CS' (CSharp). Short form is '/l:'.
This command will put inside your C:\myProxyScripts the auto generated proxy.
if your using the WSDL file in your computer, just change the URL to your full path, for example
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts C:\myProxyScripts\myWsdlFile.wsdl
Note: your Generated proxy will be called the Service Name, the one you have specified, in our example, as:
<wsdl:service name="TranslateService">
I hope this helps you, understand the WSDL, the Auto Generated Proxies and that you can manage now everything in your end to fulfill your client wishes.
You can use the wsdl utility from microsoft to generate the server interfaces and implement them
Here is a short description of the WSDL utility.
wsdl.exe -
Utility to generate code for xml web service clients and xml web
services
using ASP.NET from WSDL contract files, XSD schemas and .discomap
discovery documents. This tool can be used in conjunction with disco.exe.
I have a WPF application in VS 2008 with some web service references. For varying reasons (max message size, authentication methods) I need to manually define a number of settings in the WPF client's app.config for the service bindings.
Unfortunately, this means that when I update the service references in the project we end up with a mess - multiple bindings and endpoints. Visual Studio creates new bindings and endpoints with a numeric suffix (ie "Service1" as a duplicate of "Service"), resulting in an invalid configuration as there may only be a single binding per service reference in a project.
This is easy to duplicate - just create a simple "Hello World" ASP.Net web service and WPF application in a solution, change the maxBufferSize and maxReceivedMessageSize in the app.config binding and then update the service reference.
At the moment we are working around this by simply undoing checkout on the app.config after updating the references but I can't help but think there must be a better way!
Also, the settings we need to manually change are:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
and:
<binding maxBufferSize="655360" maxReceivedMessageSize="655360" />
We use a service factory class so if these settings are somehow able to be set programmatically that would work, although the properties don't seem to be exposed.
Create a .Bat file which uses svcutil, for proxygeneration, that has the settings that is right for your project. It's fairly easy. Clicking on the batfile, to generate new proxyfiles whenever the interface have been changed is easy.
The batch can then later be used in automated builds. Then you only need to set up the app.config (or web.config) once. We generally separate the different configs for different environments, such as dev, test prod.
Example (watch out for linebreaks):
REM generate meta data
call "SVCUTIL.EXE" /t:metadata "MyProject.dll" /reference:"MyReference.dll"
REM making sure the file is writable
attrib -r "MyServiceProxy.cs"
REM create new proxy file
call "SVCUTIL.EXE" /t:code *.wsdl *.xsd /serializable /serializer:Auto /collectionType:System.Collections.Generic.List`1 /out:"MyServiceProxy.cs" /namespace:*,MY.Name.Space /reference:"MyReference.dll"
:)
//W
Rather than changing the generated endpoint, uou could add a second endpoint and binding definition with the configuration you need, then in your code just put the name of the new endpoint in your service client constructor.
Somehow I prefer using svcutil.exe directly than to use the "Add Service Reference" feature of Visual Studio :P This is what we're doing on our WCF projects.
I take your point, svcutil is definetly the more advanced way of adding and updating service references. Its just a fair bit more manual work when "right click, update reference" is so close to just working in a single step.
I guess we could create some batch files or something to just output the reference code. Even then, manually checking out and updating the service code with svcutil will probably be more work than just undoing the check out on the config.
Thanks for the advice in any case.
What we do is we check out (from source control) the app.config and *.cs files that are autogenerated by the svcutil.exe utility, then we run a batch file that runs svcutil.exe to retrieve the service metadata. When it's done, we recompile the code, make sure it works, then check the updated app.config and *.cs files back in. It's a whole lot more reliable than using the oft-buggy "Add Service Reference" with Visual Studio.