Working with inherited code that reads data from one database (Visual Fox Pro) and stores it in SQL server. These are separate systems and use a WebService to send XML containing data from VFP.
A field has been added to both databases, and data has been seeded in the VFP database, but we are having problems with the WebService that is meant to sync the data. The WebService seems to be correctly generating and sending XML (with the new field and data) however it appears that the models that are meant to handle it on the .NET application are not being generated correctly and do nothing with this new field.
While viewing the object browser there is an 'OnlineAudienceWebServiceRef' within that, there is an OnlineAudienceDAL.OnlineAudienceFoxProRow which appears to contain a description of columns of the model. We are trying to add a new column to this Object (to receive the new data) but it appears auto-generated.
My question is, fundamentally, what is happening when Visual Studio is linked to a WebService? What files are generated, and how are they generated?
Given the web service correctly sends the new data, I was expecting Refs to be updated upon clicking 'Update Web Reference' from the solution explorer, but apparently that is not the case, and I would like know know what is going on.
There is an 'OnlineAudienceDAL.xsd' where we have added the new column, but we do not see that impacting the Object that is used to read the data.
According to App.config the app is using .NET v4, we are using Visual Studio 2010.
I am not familiar with .NET and the many things that are going on here, and would like to be pointed in a good direction. Sorry if this is confusing, please let me know what information I might be omitting and if anything is unclear.
Thank you for any help.
This is an example the Command Line Utility used by visual studio to generate the web service manually IF you have the WSDL (or XSD) file in a local folder. (WSDL is the Web Service Definition File)
This is in a batch file in my case... and also generates a VB file, but is easy to switch to C# I'm assuming with the last command line argument.
cd C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin
wsdl.exe "c:\development\WebServiceClients\CORE_Webservice_Interface_WS.wsdl" /fields /n:Telus /out:"c:\Development\output\WebServiceClients\referencefile.vb" /l:VB
WSDL.EXE is the core of this... below are the options...
c:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin>wsdl /?
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
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.
wsdl.exe ...
OPTIONS -
-
A url or path to a WSDL contract, an XSD schema or .discomap document.
/nologo
Suppresses the banner.
/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:'.
/sharetypes
Turns on type sharing feature. This feature creates one code file with
a single type definition for identical types shared between different
services (namespace, name and wire signature must be identical).
Reference the services with http:// URLs as command-line parameters
or create a discomap document for local files.
/verbose
Displays extra information when the /sharetypes switch is specified.
Short form is '/v'.
/fields
Generate fields instead of properties. Short form is '/f'.
/order
Generate explicit order identifiers on particle members.
/enableDataBinding
Implement INotifyPropertyChanged interface on all generated types
to enable data binding. Short form is '/edb'.
/namespace:
The namespace for the generated proxy or template. The default namespace
is the global namespace. Short form is '/n:'.
/out:
The filename or directory path for the generated proxy code. The default
filename is derived from the service name. Short form is '/o:'.
/protocol:
Override the default protocol to implement. Choose from 'SOAP',
'SOAP12', 'HttpGet', 'HttpPost'.
/username:
/password:
/domain:
The credentials to use when connecting to a server that
requires authentication. Short forms are '/u:', '/p:' and '/d:'.
/proxy:
The url of the proxy server to use for http requests.
The default is to use the system proxy setting.
/proxyusername:
/proxypassword:
/proxydomain:
The credentials to use when the connecting to a proxy server that
requires authentication. Short forms are '/pu:', '/pp:' and '/pd:'.
/appsettingurlkey:
The configuration key to use in the code generation to read the default
value for the Url property. The default is to not read from the config
file. Short form is '/urlkey:'.
/appsettingbaseurl:
The base url to use when calculating the url fragment. The
appsettingurlkey option must also be specified. The url fragment is
the result of calculating the relative url from the appsettingbaseurl
to the url in the WSDL document. Short form is '/baseurl:'.
/parsableerrors
Print errors in a format similar to those reported by compilers.
ADVANCED -
/server
Server switch has been deprecated. Please use /serverInterface instead.
Generate an abstract class for an xml web service implementation using
ASP.NET based on the contracts. The default is to generate client proxy
classes.
/serverInterface
Generates interfaces for server-side implementation of an ASP.Net
Web Service. An interface is generated for each binding in the wsdl
document(s). The wsdl alone implements the wsdl contract (classes
that implement the interface should not include either of the following
on the class methods: Web Service attributes or Serialization
attributes that change the wsdl contract). Short form is '/si'.
/parameters:
Read command-line options from the specified xml file. This allows you
to specify options not available from command line such as choosing
which type of asynchronous programming model is generated. For details,
please see the tool documentation. Short form is '/par:'.
Related
Some new fields were create in Dynamics CRM.
Now need to push some data to those new fields from asp.net website.
Need to add those new fields to:
[assembly: Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute()]
namespace Xrm
how should this be done? I read that these is a tool that generates this class file (CrmSvcUtil.exe).
But I do not understand how this would work.
Is this something that need to be done through Dynamics CRM admin?
Please advise.
Thanks
This should be done by user which has System Administrator or System Customizer, because this user has to have access to all entities metadata.
Basically you should start with downloading CRM SDK, for your version of CRM. For example the latest SDK can be found here:
https://www.microsoft.com/en-us/download/details.aspx?id=50032
Install the SDK and go to the bin folder inside the folder where you installed it. There you can find crmsvcutil.exe. This tool is something like svcutil.exe - it simply generates proxy classes using CRM metadata service. So instead of referring to Account entity like that:
var account = new Entity("account")
you can simply do:
var account = new Account();
and you will have all the properties that account in your system has.
In order to generate this classes just run crmsvcutil.exe using windows command line with proper credentials (it's very well documented if you run it without any parameters). example usage would be:
crmsvcutil /url:https://orgname.api.crm4.dynamics.com/XRMServices/2011/Organization.svc /u:user#orgname.onmicrosoft.com /p:password /serviceContextName:XrmServiceContext /out:Proxies.cs /n:Xrm
this would generate file Proxies.cs, containing namespace Xrm (the one you have posted in your question) with all the entities and fields. Of course the parameters may vary based on what type of organization you are connecting to. If you have problems with specifying proper values then simply put /il as last command line parameter - it will open an interactive login form, that would make it simpler for you to pass proper connection data.
I've been given a WSDL file and several XSD files to build a web service for. Right now I'm trying to just get it setup to receive requests and respond.
My experience with WebServices is limited to the old asp version with an asmx file etc.
There is a lot of information in the XSD files, I don't want to build out the classes by hand, nor do I really understand exactly what that would entail anyways (I'd imagine just an xml serializable class but haven't looked into it).
Where do I start with this? I looked into WCF but its completely foreign to me so I'd kinda rather use the old style, but I'm struggling to find any info on how to set that up or get a head start with automated generation of classes from the XSD files.
I did try WCF a bit, but WSCF blue gives me errors (Cannot import wsdl:portType) when I try to generate the WebService code. And svcutil.exe will generate some of the XSD file info but not all of them for some reason.
So two questions:
How can I generate some stub classes from XSD files to get this going
A tutorial/walkthrough for generating a WCF service from a WSDL and multiple XSD files that does not use wscf blue?
Assuming you have a WSDL to start with, you can do the following. I did this when tasked with implementing an intermediate dispatch layer on top of an existing web service. The new service should expose the same interface as the original service but perform different functions internally. Note that I am talking about "classical" WCF services here (SOAP-based).
Step 1: Create code for the service interface from the WSDL
wsdl.exe /si /out:<targetfolder> <url-to-wsdl>
This generates a .cs file that contains the interfaces and additional data types (for transfer objects). Note that this file is not WCF-ready yet as wsdl.exe seems to assume you want to create an old .asmx service.
Step 2: Import interface code into your project
Add the generated file to your project. Add attributes for making the interfaces and their operations WCF-ready. You need to add [ServiceContract] to the interfaces and [OperationContract] to the operations.
Step 3: Create the WCF service
Create a WCF service (.svc file) and get rid of the generated interface. Instead, make the service implement the contract(s) from the generated interfaces. Now, you can implement the new functionality.
Step 4: Adjust the remaining binding, authentication settings etc. to match the original web service.
You can use the svcutil.exe to generate proxy .cs classes and app.config files for your client part of the service setup, from the wsdl and xsd files.
Following is a cmd that will will generate a proxy from the visual studio cmd line:
svcutil.exe c:\OutputFolder\ /o:serviceproxy.cs /config:app.config "C:\WSDL And XSD Folder\*.wsdl" "C:\WSDL And XSD Folder\*.xsd"
These might help you get started - if you plan to go the RESTful route:
http://www.codeproject.com/Articles/571813/A-Beginners-Tutorial-on-Creating-WCF-REST-Services
http://msdn.microsoft.com/en-us/library/bb412178.aspx
http://nareshkamuni.blogspot.com/2011/12/window-communication-foundation-wcf-in.html
More in depth - http://www.thatindigogirl.com/ - Michele Leroux Bustamante from a few years ago.
Not so much a walkthrough - but has good info http://rest.elkstein.org/2008/02/what-is-rest.html
I am writing a custom piece of code that dynamically creates modified document libraries. I've attempted to create a document library template, which succeeds in the UI but cannot be found via-webservices.
So to get to the point - I am attempting to:
1. Set "Allow Management Of Content Types" on the list.
2. Add a new Content Type (Already Created) to the list.
3. Set the new content type as the default content type.
4. Remove the "Document" content type from the list.
So far I have succeeded in being able to "Apply" the custom content type but the others are evading my grasp. The methods I have attempted are through the Lists.asmx service and the method described here: http://msdn.microsoft.com/en-us/library/websvclists.lists.updatelist.aspx
I tried setting the Flags property and a few other potential candidates with no success and no error messages complaining about what I was trying to attempt.
One limitation is that I do NOT have access to the sharepoint dll where this is living.
Once completed - this would be a plugin living in another non-sharepoint system. The only option to include the SharePoint client dll's would be to perform an ILMerge.
EDIT:
http://msdn.microsoft.com/en-us/library/sharepoint/jj193051.aspx (SharePoint 2013 Web Services)
http://msdn.microsoft.com/en-us/library/ee705814(v=office.16).aspx (SharePoint 2010 Web Services)
and yes - technically the ASMX services sound like they're on their way out: http://msdn.microsoft.com/en-us/library/sharepoint/jj164060.aspx
Edit: Tags are relevant to the question.
use SharePoint Client Object Model. This is a library that wraps calls to webservices that allows among other things to batch commands.
The operations you mention are all available.
here is a link to an article that explains Client Object Model:
http://www.codeproject.com/Articles/399156/SharePoint-2010-Client-Object-Model-Introduction
The article focus on ListItems but you can also interact with list properties, even web properties if you want.
Please note that you don't need to run Client Object Model from your sharepoint server. Note the "Client" part in the name.
can anyone tell me if there is a tool for creating the strongly typed classes (available via the schema) - i suppose similar to Paste as XML type ..
But i was hoping for a tool that i could run to automatically update the classes automatically when there are changes
Does anyone know if something like this exists?
If you have a WCF Data Service (f.k.a. "Astoria" or "ADO.NET Data Service"), you can use the regular Add Service Reference in Visual Studio, point it to the SVC file for the service, and voila - you get a data service client side proxy, with strong types and all, and the ability to query your data service (a REST service) using LINQ - LINQ-to-REST, so to speak!
See the MSDN docs for a few more bits of info.
I have numerous Web Services in my project that share types.
For simplicity I will demonstrate with two Web Services.
WebService1 at http://MyServer/WebService.asmx
webService2 at http://MyServer/WebService.asmx
When I generate the proxy for these two services I use:
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx
/appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs
The problem is that the appsettingurlkey is the same for each Web Service
in the proxy file. I want to be able to specify multiple
appsettingurlkey parameters. How is this accomplished? I figure
since the /sharetypes parameter became available, there should be a
solution for specifying the appsettingurlkey specifically for each
Web Service identified.
If this is not possible with the wsdl.exe, what would you propose I do? I would rather not update the generated code that wsdl.exe outputs and I don't want to go through my whole application passing in the Url to each instance of the Web Services.
The proxy classes generated are partial classes, so my solution would be to add your own constructor in a different (non-generated) code file, which explicitly reads a different setting for each proxy.
To suplement Elijah's own answer, here's the email answer I gave him.
I had to blog it because the XML didn't paste well into this text box: http://www.rickdoes.net/blog/archive/2008/09/29/wsdl-shared-types-and-configuration.aspx
Ahh, instead of creating another partial class with an overloaded constructor passing in the Url, the following additional parameters to the wsdl.exe will solve my problem...
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx /appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs /appsettingurlkey:BaseSoapUrl /appsettingbaseurl:http://MyServer/
If the web.config has a BaseSoapUrl appSetting, then it will use that to replace the http://MyServer/ sub string from the MyProxy.cs. If the appSetting is not present, then it will just use the path provided in the wsdl.exe (example: {BaseSoapUrl}/WebService1.asmx when using the appSetting or http://MyServer/WebService1.asmx when not using the appSetting).
A thanks goes out to Rick Kierner for pointing me in the right direction.