Is TFS 2015 is compatible with SharePoint 2016? Google search shows it is not compatible but didn't find any updated reference.
It's probably not compatible. The TFS integration with sharepoint is, at this point, more or less abandoned in favor of more flexible built-in dashboards, graphing, and reporting capabilities. You can still use Sharepoint for document management without having it explicitly integrated with an instance of TFS. I always recommend examining what you're using Sharepoint for in the context of TFS. I think you'll find that it's unnecessary to have it integrated.
Related
In Dynamics CRM 2011 SDK the Xrm.Page Script Library template was at SDK\Templates\Xrm.PageScriptProjectTemplate location. But in CRM 2013 SDK no such location exists.
Also no such file campe up in folder search.
Do anybody have an idea about this?
I was the author of that template and chose to distribute it in the CRM SDK for CRM 2011. However, things got really busy and we just didn't have the bandwidth to maintain it. A third party solution: CRM Solution Manager (http://crmsolutionmanager.com) picked up the form scripting parts of it and added improvements along with many other useful capabilities. I would take a look at their solution if you found it helpful.
As far as I know the template has not been released for CRM 2013.
You can use the CRM 2011 one, but of course will not contains the new client methods introduced with CRM 2013.
Is there a best practice for versioning SharePoint features?
Our SharePoint product gets a release every 3-6 months, and we need a way of clearly differentiating between the new version and the old version. We also need to support simultaneous installations of the new and old feature so that clients may test the new stuff before deploying it.
Versioning Features is not supported in Sharepoint 2007. In Sharepoint 2010 you can Version Features like you normally would version assemblies.
See the following post for more details: Feature Versioning and Upgrades in SharePoint 2010
Here is a excellent webcast by Jeremy Thake on feature versiong and upgrade :
http://sharepointdevwiki.com/display/SPPodCasts/2010/06/22/SPWebCast+019+-+Deep+dive+into+feature+versioning+and+upgrade+support+in+SharePoint+2010
Check out chapters 8 and 9 of our free SharePoint development guidelines. We have been using this strategy successfully for the last few years in both SP2007 and SP2010.
I have used SharePoint's export/import tool in SharePoint 2007... Wasn't too thrilled with it. I am now having to do the same thing in SharePoint 2010. First off, just as a refresher, what all is migrated when using the export/import utility? And, is the export/import the same in SP 2010 as it was in SP 2007? If any issues have been seen with the SP2010 export/import utility, I would like to hear that as well. Thanks in advance.
From my experience Powershell export/import works much better in SharePoint 2010 than the stsadm versions did in 2007. However, I also know that export/import improved considerably over the full lifetime of the 2007 product and continued to receive updates up to at least SP2, maybe further with hotfixes and cummulative updates.
I haven't found much missing after experimenting with the flags when exporting then importing a list or a library. I haven't tried the moving sites as much, but I know it is improved over the release version of SharePoint 2007.
The VSTO bit I understand. Visual Studio has the project templates to get you started with creating nice .NET based add-ins.
But where is VSTA? I installed the SDK but it seems to be gears towards adding extensibility to your own applications.
I had thought that VSTA was like the new VBA for Office 2007. Infopath 2007 seems to be VSTA enabled but I cannot seem to find where Excel 2007 is also VSTA enabled.
Am I missing something ?
As I understand it, VSTA is not a 'new VBA' nor built into Office 2007, but a separate 'Super-VBA with .NET' that must be licensed from Summit, and distributed as part of an external application. I think it's just targeted at ISVs wishing to extend Office, but the blurb about it also contains this gem:
Perhaps the feature most applauded by enterprise BDMs and SI’s is that VSTA customizations are seamlessly opened by any version of Visual Studio enabling professional developers to continue to enhance applications originally created by end user developers – a feature requested by many enterprises because applications often grow in sophistication over time.
I've not bothered googling BDMs and SI means le Système International d'Unités to me, but I took this mean that you can take the horrible mess of excel VBA that your traders used to turn worthless morgages into goldmine CDOs (and then bailouts), and your 'real developers' can open it in Visual Studio and sort the mess out (or just quit...).
also VBA and VSTA can exist together:
http://blogs.msdn.com/vsta/archive/2006/07/31/684514.aspx
If I understand correctly, VSTA is a new technology that provides a "standard" short-cut route to extensibility for application vendors. So it may appear in Office apps in the future or it may not, but it's not there now.
If it becomes supported by Excel, Word and the like, then the UI (Visual Studio Shell?) should be distributed as part of the package.
But I may be miles off-base...
VSTO 2005 is available to install by itself as a complete development environment
Read more here...
http://msdn.microsoft.com/en-us/library/54ds2za4(v=vs.80).aspx
I am new to developing for Office Forms Server / MOSS 2007. I have to choose between designing my web-based forms and writing code for them in Visual Studio Tools for Applications (aka VSTA) or Visual Studio Tools for Office (aka VSTO). VSTA is included free as part of the license for InfoPath 2007; VSTO, also free, requires Visual Studio 2005 / 2008. I have licenses for both of the products and cannot easily decide what the pros and cons of each IDE might be.
This explains it better than I can: http://blogs.msdn.com/andreww/archive/2006/02/21/536179.aspx
Given the fact that the license for VSTA comes with InfoPath, I'd probably run with that.
To add to Bennor's answer I would avoid writing code "behind" InfoPath forms entirely. This is a desperate attempt to make 'dumb XML' as much as possible instead of "smart" XML that is entangled with code. Failing this, my next choice is VSTA because historically these solutions (at least the ones I have written) have a lower security risk and can run on more diverse Office environments.
The last resort is to use VSTO. This is my bias... most of my VSTO investments are in Microsoft Word.