We are interested in making some custom VS project templates for our developers and this would be a great help. More specifically, we want to create a unified starter VS project template for new SharePoint developers that could target both full trust solutions, CSOM/JSOM, and REST to build/deploy IA to both SharePoint and SharePoint Online. The idea is to add/manage common frameworks and utility classes for our newer developers so that we are always utilizing an updated managed VS project template, no matter what the project requirements dictate.
So is there any way we could use the VS designers for Content Types, Lists, and other SharePoint elements in non-standard SharePoint or SharePoint Apps VS project templates?
Related
I am given a sharepoint location from my organization. I have to save my Visual Studio project onto this location and use it as a repository/TFS/AzureDevOps like integration where my team members can access the project, map them to their space and work on the project.
Please help on this
Agree with #Daniel Mann. SharePoint is used to share and manage content, knowledge, and applications to empower teamwork, quickly find information, and seamlessly collaborate across the organization. SharePoint isn't designed to be a source control tool for code. Based on my knowledge, it won't integrate with any IDEs, and it does not have customized GUI to manage source control code, etc.
There are many version control tools, like Azure DevOps Services, which can host unlimited free private repos and start free.
I'm looking for suggestions on how best to share VS projects across Team projects in TFS (currently 2013 on-prem, but will soon upgrade to 2017 or VSTS). Our primary use case is for Request/Response models for Web API projects, but we've recently started trying to share more utility code and custom parsers across our development teams as well.
In our current setup we're using self-hosted NuGet packages, but this is a manual process and error prone. It also holds us back from moving to VSTS because Package Management isn't included in the Basic tier.
We could probably reduce the dependency on shared models by using Swagger to document our APIs, but that seems like a cop out.
Any suggestions?
It's not suggested to reference projects outside your solution root. You should make a project reference or create a NuGet package.
Since your projects are across Team projects, Nuget package is still the recommended option. In VSTS and TFS 2017, you can host your NuGet packages using Package Management feeds. Check: https://www.visualstudio.com/en-us/docs/package/overview.
Currently most of the development in the company I work for is controlled via VSS. I've installed Team Foundation Server for the development at our site.
There is a future project that will involve new developement, but referencing older code bases hosted in VSS. My preference would be to use TFS for the new development, but I'm unsure if a VS2010 solution can have projects using different source control providers.
You'll need to change the source control provider manually (unbind - change SCC provider - bind) each time.
No Visual Studio does not allow for mixing source control providers within a solution at the same time.
My SharePoint Visual Studio solution structure currently contains these projects:
Common: contains extension methods, helpers, frequently used controls, etc.
Logging: would normally be included in Common but contains calls to native methods so marked 'unsafe'
Site-specific project: one for each distinct site, containing features, web parts, event receivers, etc. specific to that site
Console app: console app projects as/if needed
I'm using WSPBuilder hence each project (apart from the console apps) has its own SharePoint WSP solution file.
Is this a good way to split up SharePoint code? What approaches do you use?
That seems reasonable, though you might want to be careful about the deployment of the shared projects - The deployment script probably includes updating the common package, which isn't good for older site specific projects.
For most projects I prefer to have a single solution package with necessary shared libraries included - usually being installed to the GAC.
If you aren't doing this already, I would consider bundling your common code into one or more features and have the non-common code be in a feature with a feature dependency to the common code. You may want to have the common code use a different WSP or the same WSP - not sure of all of the pros/cons of that.
Say I want to create vb.net application in Visual studio 2005.
What is the difference between File->New->Project vs File->New->Web Site?
EDIT
I am aware that when using New->Project there are many more options available but if one wants to create just .net web application, would it make a any difference what option you choose?
Here's a good link about WAPs (web application projects) and the differences between WAPs and website projects.
In 2003, your only option (if I recall correctly) was the WAP. 2005 introduced the concept of website projects, where all your code is uploaded to the server and compiled into DLLs on first access. This allows you to easily change your code without having to compile and publish the dlls.
Not a lot of people liked this new way of doing it, so MS created an update to allow for 2003 style WAPs in 2005. 2008 retains both options.
The File->New->Web site option is the only way to create a website application (or, at least it is in 2k8). The only way to create a WAP is to do File->New Project->Web->...
If you create a project, all cs files in your project will be compiled into one DLL. Instead, if you choose to create a website, all your app_code will be compiled and cached on the fly.