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.
Related
I have restored a content database to SharePoint 2010 (which we completely broke after upgrading TFS to 2013).
When I open the content site, all the sub-sites are listed, but clicking one of these "sub-sites" goes to page not found. (The sub sites were created from TFS 2012 when new team projects were created).
How do I get the team project sites to work again?
You likley do not have a managed path configured for your SharePoint sites. If you look at the URL of the sites that you can't see you should be able to figure out the managed paths to add.
http://technet.microsoft.com/en-us/library/cc261845(v=office.15).aspx
You are kinda defining mount points for site collections here. Without that mount point SharePoint will not render your sites.
I am new to SharePoint, I am using SP 2010. I am asp.net developer but I don't understand if I have web.config under 80, so what are those web.config files under 14 folder, can you briefly discuss it?
I found two so far, There is one under 14\Templates\Layouts and under 14\CONFIG
Thanks
SharePoint development is similar to ASP.NET development but there are some major differences you need to be aware of. One is the use of Web.config to store application settings.
I wrote a blog post with links to several resources to help new SharePoint developers get started: Getting Started with SharePoint 2010 Development–Links and Resources
I suggest you start by watching the SharePoint for ASP.NET Developers talk to get an idea of the SharePoint architecture and development/deployment model.
You will find a lot more in 14 hive :) They are there because they are web.config files for different parts of the entire sharepoint application pages. For example the one in "14\layouts\" is for general application pages, site settings, regional settings, ... for instance. the one in the 14\layouts\admin is for centeral administration pages.
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?
During site creation using SharePoint, SharePoint offers some templates. If we need to create a site other than a template offered, how should we proceed?
You have 2 options:
Site Templates
Site Definitions
Many people use those terms interchangeably, but there are big differences between the two.
Site Templates
Site templates are easy to create. Basically, you create a site using a ite definition (e.g. the blank site) and start customizing it. You can add lists and libraries and setup the site however you want it. Then, go to Site Actions > Site Settings > Save site as template. You can save your site as a .STP file. The .STP file basically records everything that you added or changed on your site after site creation.
Once saved, your site template will show up in your site template gallery. You can go to the site template gallery and save the .STP file offline. Your new site template will be available in the subsite creation page in the "custom" tab. The template will only be availalbe in this site collection, unless you add the .STP file to the site template gallery of another site.
You can deploy site templates globally. So, if you want everyone to see a STP in their subsite creation page, you can run the following stsadm command:
stsadm -o addtemplate -filename BoardDirectors.stp -title "Board of Directors"
You can retract site templates whenever you want without affecting the sites that used them for creation. This makes them easy to version, as long as you don't want to push updates to existing sites.
One big problem with site templates is that you cannot staple features to them.
Site Definitions
Site definitions are collections of XML files deployed to the 12 hive. They are harder to develop; you basically have to use Visual Studio. The XML files have to be packaged into a SharePoint WSP and deployed using STSADM.
Creating a site definition gives you the most control over your site. Another benefit is that sites using the site definition will always reference the site definition's files, so updates will be recognized by sites using that site definition. For example, if you find a bug, you can fix it in one spot and all sites using that site definition will be fixed.
Note that withdrawing a site definition will break sites that use it.
Recently, many SharePoint experts have recommended staying away from creation new site definitions because of the overhead. Instead, if custom functionality is needed, they recommend coding custom features and just activating those features on sites.
Think about which option you need. In our organization, we chose not to create any new site definitions, and use site templates sparingly. Custom functionality is driven primarily by the use of features.
You are talking about custom "site definitions" and custom "site templates". Google those terms and you'll find tons of information.
You can design your own custom templates. Install VSeWSS extension for Visual Studio and it has a project type called "Blank Site" template. You can use it as a base starting point and customize the solution generated to your needs. All the information required to do so is available in the help document that comes with VSeWSS.
I’m trying to publish an InfoPath form to a SharePoint document library, and have the form be viewable in a web browser.
The problem is that in the InfoPath publishing wizard tells me that although the form is browser compatible, that it cannot be browser enabled because of one of the following:
The Server is not running InfoPath forms services
The necessary features are not available on the site collection
The policy setting on the server does not allow a user to browser enable forms.
Well, I’ve verified that the SiteCollection has an active feature called “Office SharePoint Server Enterprise Site Collection features”, which includes Form Services, so I assume that the first two issues are not the cause
Also, I’ve verified in Central Admin that the Forms Services are configured to allow browser-compatible forms to be viewable in the web browser. So the 3rd reason doesn’t seem to make sense either.
I've tried applying different Security levels to the form: Restricted/Domain/Full Trust, but that doesn't seem to have an effect. I have been able to publish this form to a different SharePoint site, so I'm assuming that the issue is with the configuration of the SharePoint site, not the InfoPath form
Does anyone have any other ideas as to why this might not be working?
Thanks for any help you can provide!!
Make sure in the Form Lib Advanced Setting section you have the Option "Display as a Web page" is set "Opening browser-enabled documents"
Try testing the XSN file against the MOSS server by copying the file to the server itself (c:\temp for example) and running the following command:
c:\temp> stsadm -o verifyformtemplate -filename myform.xsn
The tool STSADM.EXE sits in %programfiles%\common files\microsoft shared\web server extensions\12\bin so add this to your %PATH%.
Post the answer back here if it still baffles you.
Besides the recommendation from #x0n to check if directory has been allocated as usable, check the event viewer and see if anything is showing.
As a stupid but check item go to:
Central Administration > Operations > Convert License Type
and ensure that you have the enterprise Client access listed.