According to MSDN, for deploying custom web service, we need to create *wsdl.aspx and *disco.aspx files, and put them with .asmx together under _vti_bin folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi). And put the dll under bin folder of the root of sharepoint virtual directory. It works correctly for me.
However, i also found that if i put .asmx file under the root virtual directory without creating those *wsdl.aspx and *disco.aspx files. It can work as well and much easier than the above way. So i'm wondering what's the potential issues in this way?
Without the WSDL and DISCO files, folks' web service clients/consumers may have a hard time "discovering" your service's contract. If that's not a concern for you, don't worry about it.
I have created several web services in SharePoint 2007 that were simply deployed as http://.../_layouts/mySubFolder/service.asmx. It works! For SharePoint it does not matter whether the presentation layer is HTML or XML for a web service (in both cases security must be applied, can be addressed both as http://server/_layouts/mySubFolder/service.asmx and http://server/sites/subsite/_layouts/mySubFolder/service.asmx
Things that are wrong thing about it
the word "layouts" implies "something to do with how it looks like".. which is not the case when we speak about web services
when migrating to SPS2010 where WCF services come into play, it will be different. However, I have not yet played with SPS2010 and do not yet know, how different. (Somehting about it here - http://blog.mastykarz.nl/wcf-sharepoint-context/)
Quite an old post but just thought i'd add to this as I don't believe the responses to date give the relevant detail on why SharePoint is setup this way.
The reason why you deploy webservices to ISAPI\vti_bin for SharePoint is because there are specific modifications made for requests to this folder to allow SharePoint to build an accurate discovery and WSDL file for the service based on the current virtual path of the service, not the path in the IIS site.
More specifically wsdisco.aspx and wswsdl.aspx handle requests to this virtual directory and will call the relevant disco.aspx and wsdl.aspx to generate the discovery xml or wsdl xml correctly based on the current SharePoint url.
If you add a service reference to your project for http://sharepointsite.com/sitecol/subsite/_vti_bin/lists.asmx the context for requests made on that url will be relevant to /sitecol/subsite as you would expect.
However if you add a service reference to http://sharepointsite.com/sitecol/subsite/_layouts/MyCustSvc.asmx the context will be fixed to http://sharepointsite.com/ because the default wsdl generator for ASP.NET is not aware of the SharePoint virtual paths. In which case calls to SPContext in the service will not work as expected.
There is an excellent post here with examples explaining this:
Where do you deploy custom SharePoint web service files to?
Related
I've got an umbraco site which I deploy to an azure web app service. The data is on an azure sql database. I have been able to deploy this successfully, and can verify that all the data I expect to be there is present in the content view.
However I have added content on various pages, in rich text editors, and on my local site I can see this content on the site. But on my deployed site the content in rich text editors is only visible on the content view, not on the site. I've tried publishing each item but nothing will appear.
What else can I try?
Umbraco needs some additional configuration to be treated properly on Azure. It especially affects indexes and XML caching file.
Please check the following blog post made by one of the Umbraco HQ Core developers - Sebastiaan Janssen: https://cultiv.nl/blog/making-sure-your-umbraco-site-performs-on-azure/. Go step by step to ensure if your app is properly configured.
Going further you may be in need to also ensure proper configuration for load balancing, which you can find here: https://our.umbraco.org/documentation/getting-started/setup/server-setup/load-balancing/flexible
I found the answer after a much experimenting.
I had not manually included in my project (and thus not deploying) Views/Partials/Grid/fanoe.cshtml. This file includes the and I guess I was using some default template which is using this file, rather than the other grid templates in the same folder.
i have a bit of stupid question, but i'm really having trouble with it.
I have a wsp project which i have successfully added to MOSS 2007 using stsadm.exe and deployed it via sharepoint central administration. This has created a new folder in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\ with solution files, so my issue is how to use/create workspace using this solution. I have no new feature, site type etc. in my sharepoint. The solution had been created by another developer whom i cannot contact.
Deploying it through Central Admin isn't the same as activating the feature.
There are several scopes in which a feature could belong:
Web
Site
Web Application
Farm
Only solutions targeted to Web or Site can be activated within SharePoint UI. The others are done through Central Administration. On activation of the feature is when work is performed.
Site: Site Collection Features
Web: Site Features
If you want to see what's in the WSP, you can make a copy and change the extension to .CAB and browse the files. Any DLLs will be likely deployed to the GAC.* If you look at the other XML files you can see what's in them and guess where they are going. Chances are pretty big the feature is Site or Web scoped. If it contains a SharePoint Timer Job, it'll be either Web or Farm scoped but could be Site scoped as well.
The only thing that could be complicated is features can be marked as hidden. If this is the case, the feature won't show in the Site- or Site Collection Features area. Instead you'll have to activate using an STSADM command (activatefeature) passing the name or GUID along with the URL where you'd like the feature activated. You can find this info by opening the WSP and looking at the XML files within.
*Some DLLs might just be feature receivers - code that will run on Feature Activation or Deactivation to do some additional things through the OM.
I'm in the process of moving a complete sharepoint install to a different server.
Can anyone tell me if it's possible to just move the existing Shared Services Provider rather than starting from scratch?
All the best
You really need to move the SSP in concert with everything else in the farm. The two things to move are 1. databases and 2. the file system.
A .doc file for moving all of the SharePoint databases has been published here. Microsoft will soon have an updated procedure for this published on TechNet, according to the To The SharePoint blog.
Then to cover off any file system changes, I would set up a clean install of SharePoint (if you didn't need to already by following the document mentioned above) and do a file comparison between your source and destination SharePoint application servers. I usually use WinMerge as its free but Beyond Compare is also good. Also check any custom solutions are deployed on your destination server.
By ensuring your databases are moved correctly and all of your files are in place you should be OK. Make sure you test every custom component on your destination server before erasing the source databases and files (even better, archive the source).
Yes, create a new SSP and move the applications.
How to on migration of applications here
For moving the SSP to a new farm
Or try the Microsoft SharePoint Administration ToolKit v2.0
For another view of this
Using the SharePoint API, how can I modify an extended webapp web.config file?
I have to do some changes in this file to specify the connection string, membershipprovider, etc... for using Forms Authentication.
Currently, I can change the "master" webapplication web.config file, but not the extended one.
Edited
I'm using Sp 2007. I'm already using SPWebConfigModification class to modify the parent webapp. Thoses modifications are propagated to the extended webapp. I have to change ONLY the extended one. But I don't find the way to do it.
What I'm trying to achieve, is to program a little wizard that:
Shows a WebApp list so the user can select one
Extend that selected webapp to a different zone
Configure that extended zone to use Forms Authentication
Thanks
I got an answer form a blog.
In your case , you need to write a Web Application scoped feature which after you provision your site using your C# app, it is deployed to the newly-provisioned site and in the receiver of the feature you inject the required web.config settings because in that context configuration API is obtainable , but again bear the following in mind:
If you don’t use SPWebConfigModification class and either use ASP.NET 2.0 configuration API or your own mechanism , propagating changes across the farm is YOUR RESPONSIBILITY. If this happens on an standalone installation then you don;t need to be worried about this.
So it cannot be done externally. We have to do a feature in order to acheve this.
Thanks
Quick answer: look into the SPWebConfigModification class. I am assuming you're using SharePoint 2007. The best way to learn about this is to dig into open source projects:
Google code search: http://www.google.com/codesearch?q=spwebconfigmodification&hl=en&btnG=Search+Code
This project on CodePlex looks like it's one big SPWebConfigModification: http://www.codeplex.com/ajaxifymoss/Release/ProjectReleases.aspx?ReleaseId=13360
I'm getting a 404 error when trying to run another web service on an IIS 6 server which is also running Sharepoint 2003. I'm pretty sure this is an issue with sharepoint taking over IIS configuration. Is there a way to make a certain web service or web site be ignored by whatever Sharepoint is doing?
I found the command line solution.
STSADM.EXE -o addpath -url http://localhost/<your web service/app> -type exclusion
I depends on what you mean by side by side, if you are trying to make something inside the same URL path as sharepoint then the above answers about managed paths should do it for you, but there is also nothing stopping you from just creating another Web Site inside of IIS, sharepoint will only take over the requests coming to its specific web.
you'll have to go into the SharePoint admin console and explicitely allow that web application to run on on the same web site as SharePoint.
I believe it is under defined managed paths.
Central Administration > Application Management > Define Managed Paths
Hasn't this change from 2003 to 2007? There's no longer an excluded paths option.