Base:
I have created a ASP.NET web part to be deployed to a Sharepoint 2010 site. This web part is using a external web service, a WCF service that is hosted else where, not on the same machine as the Sharepoint site. The web parts are installed on the sharepoint server using a CAB-file that is created via a deploy project.
Issue:
My issue is that I have web service binding configurations in the web.config of my ASP.NET web part solution that I need to modify based on what customer is using it, so I need to be able to modify my binding address after installation (or during).
Other:
I have seen solutions using the SPWebConfigModification, but I have no local installation of Sharepoint so that is not an option. I have also seen pure C# solution where the endpoint address is hard coded in the assembly, but this will prevent me from modifying the address after compilation of the web part. The best way would be to have an external txt/xml-file that I can use from my web part to get the endpoint address from, or a smart way of updating the sharepoint web.config not using SPWebConfigModification.
so...
any one have a awesome solution to my issue?
Can you use custom webpart properties that will contain the WCF endpoint information? This way you will be able to configure your webpart(s) after they are added to a page. The properties are reachable from the webpart code so you can generate the wcf proxy in the runtime with no custom config files in the solution.
this article might help you with the custom properties http://www.lamber.info/post/2010/05/21/How-do-I-create-custom-properties-in-Visual-Web-Parts.aspx
Editing web.config is almost always the wrong place to put something like this.
Maks answer is good and certainly the easiest option, if you want to store the address of the web service in one place to be used by multiple web part instances then this option may be better.
SO - What is a proper way to store site-level global variables in a SharePoint site?
Related
I don't have any code yet as I don't know where to start! I see on the web that I'd need to select
on the Access toolbar external data >> more >> data services. Then it asks to point to a xml config file. Which I don't have and would need to create. I have the connection string from a VB.net application.
sWIPConnString As String = "SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fake3465-vip.ent.agt.bb.ca)(PORT=41521))(CONNECT_DATA=(SERVICE_NAME=fictitious_service_name)));uid=APP_getinfo;pwd=thispassword;"
I'd have to convert that to an xml version. Any help would be appreciated!
Thank in advance
Pete
But those data services are not just any old plane jane web site. They are web sites that have installed, setup, and the developers of those web sites setup that data service connection. And these custom connections are NOT general web sites, and they are not general web services that many sites have. And they are not a web API written around say SOAP or some REST standard.
So unless that web site decided to adopt this Microsoft specific means and method to expose data, then you not be able to use this feature to simple connect to any old web site out of the blue. If you have a existing web site that exposes some web services? Then you have to use MSXML and consume that web data yourself. That option in Access is not some general purpose setting or feature that allows connection to any old web site - only ones that have created that web service written to the business connection options that Microsoft created.
It not clear if you planning to create some web services on the target web site (that would assume you're the developer of that web site), or you trying to consume existing web services that the given site exposes. Even in this 2nd case, those exposed web services or even REST calls has ZERO to do with the feature in Access.
so that feature is of only use for connecting to web sites that offer specific created connection based on that standard from Microsoft - it not a general web service consuming feature built into access and you can't use that feature as such.
How to make a web service call from Access? Well, it has ZERO to do with that feature. Here is a MSXML exmaple:
How to use XML web services in Access2007 which are built on Visual studio (2008/2010)
I am using VS2010 and .NET 4.0. When I create a WCF Service Application, I can easily get my service up and running. However, I am unable to find the services information such as binding configuration and address etc. Where does the template store this information so that I can modify. I know I can add my own bindings and address in the config but I want to know what is the default binding WCF template is using and modify accordingly.
I apologize for the simple (dumb) question, but in 3.5 it was in the config upon using the template
This is not something being done by the template. The application is simply using the default WCF configuration settings. See here for futher info.
I have a project that uses web references to make SOAP calls to several web services.
When I'm working locally, the services are hosted on my local machine, so the URL of each web service is something like http://localhost/blah.
When I deploy the project to a server, the URL needs to change to the production URL.
Currently I am accomplishing this with a prebuild event that does a find-and-replace on each URL and overwrites it with the deployment URL before deploying. Surely there is a better way.
Can someone enlighten me on the best way to change web references for deployment?
This happens to be a VB.NET project in Visual Studio 2010.
If you set the URL behavior of the Web reference to dynamic, the application obtains the URL at run time from the appSettings element of your application's configuration file.
So, you can use code to set it based on where it is deployed. This is a pretty old link, but I think it should help:
http://www.codeproject.com/KB/XML/wsdldynamicurl.aspx
I can read the SP lists fine and pull data out of the SP context, but I am trying to get data from an external database as well and I don't know exactly how to do that. Is is possible to add WCF communication to the webpart that will allow the Silverlight app to communicate to a WCF service? If so, any examples on how to do this?
Or is there a better way to store/retrieve custom data that I don't want to be accessable through custom sp lists?
You could use a combination of BCS/External Content Types to surface the data in SharePoint, then the SharePoint client object model to access this.
Eric,
I am not sure if i have understood your question correctly. If you have a custom webpart that loads some silverlight content and silverlight needs to access external data using wcf, then you can do the following:
If you need to deploy your wcf service in sharepoint site, then follow this article from Sahil Malik: http://blah.winsmarts.com/2008-5-SharePoint_as_a_WCF_Host.aspx
Once the service is deployed and your able to access it from ie, Add service reference in your silverlight project.
Load the silverlight application in your webpart
This link might also help:
http://blah.winsmarts.com/2008-7-SilverLight_WCF_References_in_SharePoint_-_The_right_way.aspx
I want to make use of some of the ASP.NET 3.5 capability within SharePoint 2007. In particular, I want to do the following:
Provide REST and maybe JSON through HTTP so that another product can consume SharePoint content.
Provide AJAX web parts within SharePoint. These will probably have little to no server side controls. Most content will be loaded using Javascript and hitting an external system (primarily not SharePoint) over HTTP that provides REST or JSON.
Provide this capability as a product. This is not a one-off solution for a single implementation.
My main concern is push-back from IT groups not wanting to change their SharePoint environment to allow for the product to work. So, I'd prefer to be able to say that what I'm doing is "supported by Microsoft", but I'm not sure that will be the case.
I realize that I could create a separate (non-SharePoint) web site on the SharePoint server(s) for WCF endpoints that provide SharePoint data to an external application. I would rather not do this because that won't help my web parts (if they need help) and that makes deployment harder. Proper SharePoint deployment will automatically have SharePoint update all necessary files (e.g., web.config) on any new web front end added to the farm and this wouldn't follow that pattern. In addition, I'd lose the ability to use SPContext.Current.
I have read much of Daniel Larson's book on Developing Service-Oriented AJAX Applications on the Microsoft Platform (good read, BTW), esp. Chapter 11 on extending SharePoint. He outlines WCF, ASMX, and HTTP Handler options and for the most part recommends the HTTP Handler option. It appears that the HTTP Handler option has minimal changes to web.config.
I have also seen a blogs on SharePoint as a WCF Host, SharePoint 2007 and the Thin .NET 3.5 Development Model, How to: Get up and running with .NET 3.5 in your SharePoint environment, and Enabling .NET 3.5 in SharePoint 2007 Sites, the Lazy Way. As well as the "Silverlight (.NET 3.5) Config Feature" (and maybe even the "Ajax.Config Feature") in the SharePoint 2007 Features CodePlex Project. It seems that all of these options do some fairly drastic changes to the web.config and may not be acceptable to potential customers.
What are the opinions out there on this? What about if I want to use the AJAX Control Toolkit (I've used this before in SharePoint, but it has been a while)?
Note that we probably could require SharePoint SP2 if that helps, but I don't think it does.
Note also that Silverlight is not a requirement for the SharePoint web parts, but allowing for it might be nice.
Your first point could be solved by a custom wrapper to the SharePoint web services, presenting the API that you want to present, rather than the generic web service.
Your second point, AJAX enabled pages and web parts, is already possible - how to enable AJAX in SharePoint.
.NET 3.5 Is supported in SharePoint (as of SP1 I believe), However you will not be able to get away from making web.config changes and installing .NET 3.5 on the servers - it will likely only be there if there are already AJAX web parts in use.
Aside from that what you are looking at is largely independent of SharePoint - If you can build something as an aspx page or asmx web service you should be able to deploy it to a SharePoint site.
If you want to avoid 3.5 installation issues altogether you should be able to build something totally separate - jQuery for the web parts (no server side components needed) and for getting data out of sharepoint build something that translates calls to the standard web services into a friendlier interface.