I´m creating an application with SharePoint 2013/Visual Studio 2012. When I modify the aspx or ascx files, I need to deploy the whole application in order to view all changes and it will take almost one minute.
Is it possible to avoid the deployment when I change these ascx/aspx/js/css files?
No, deployment is only way how to propagate changes when using Visual Studio to develop SharePoint farm solutions.
But you can create JS/CSS/HTML pages using SharePoint Designer and when you will be done, import it to Visual Studio - SPD saves changes directly to SharePoint and you will see result imediatly...
Related
Can anyone help in below scenario?
1-Before some time I created and deployed visual studio custom page-layout in production.
2-Users created some pages using that page layout and add content.
3-Now I have done some enhancement in that and deployed again
4-If I am creating new page its showing changes but existing pages not showing that changes??
Try deactivating and reactivating the feature that contains the layouts.
I'm working on SharePoint workflow (SharePoint 2010) in SharePoint designer 2010. I was published it many times without problems. But after many publishes (I thing 30) SharePoint stop to changing workflow (I published it without any error and I can find new workflow release in SharePoint web interface).
I published new version (with new commands) but workflow still use old one. But when I modified one of commands which was in workflow previously the modification will appear in next run. I need to add to workflow new commands. My only option is to rewrite whole workflow to new one. But this is much complicated workflow and rewriting takes me long time. Is this behavior normal? Is it some bug? is there any patch or workaround?
This happens most of the time due to the caching mechanism in SharePoint/SharePoint Designer. What you need to do is the following:
Close your SharePoint Designer
Navigate to the following directory: %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
Delete everything in this directory
Navigate to the following directory:
%APPDATA%\Microsoft\Web Server Extensions\Cache
Delete everything in this directory
Open SharePoint Designer and try to publish your workflow again.
Everything should now work.
For SharePoint Designer 2013 you need to do the following steps:
Go to File > Options > General > Application Options
In the General tab, under the General header, check if the "Cache site data across SharePoint Designer sessions” is ticked. If it is, unchecked it.
Open your SharePoint Designer again and try to publish your workflows.
There is an easy workaround: You need to enable major versioning for the Workflows list. By default, that list is not visible but you still can get to the admin page:
Open SP Designer
Goto All Files
Right-Click Workflows list -> Properties
On the ribbon click Administration Web Page
On the admin page go to Versioning Settings
Enable major versioning
Save your workflow
I created a webpart in a sharepoint, tried googiling how the webpart would need to be added to the webpart gallery but couldn't find a good answer or a "how to" how it is done programatically through the activateFeature?. is there an online source which I can follow?
I am not fully clear on your question. Going on an assumption you have developed a webpart using Visual Studio (say 2010 or 2012), then the addition of your webpart to the webpart gallery of your site collection will be taken care of when the solution (the compiled WSP) is deployed (whether you do it through Visual Studio deploy commands, PowerShell etc.) to your target SharePoint instance. If this is not your question, then let us know.
I'm using Visual Studio 2010 to develop a SharePoint Server 2010 solution. Part of this includes custom Page Layouts, but when editing them, intellisense is completely broken, since Visual Studio doesn't appear to know how to handle them. Here's what I've done:
Created a new blank solution
Right-clicked on the solution and created a new "Empty SharePoint Project"
Right-clicked on the project and created a new "Module"
Renamed sample.txt to MyPageLayout.aspx or created a new ASPX Web Form
At this point, intellisense for the new Page Layout is broken. It gets even worse with tools like ReSharper installed. Also, things like "Format Document" will break the Page Layout (by for example changing asp:Content to asp:content)
What I've tried to get intellisense working:
Added a Web.config from a standard Web Application Project to the root of the SharePoint Project - made no difference.
Added the ProjectGuid for a Web Application Project to the SharePoint project file - broke the project.
Is there any way to get intellisense, and the rest of the support Visual Studio can offer for Web Forms, available when developing SharePoint 2010 Page Layouts?
I have followed your post to some extent.
Using VS2010 (On an x64 machine)
Create a blank SharePoint solution. (this properly combines your #1 & #2)
Add a module (in SharePoint a module is like a folder or resource container)
added a new class to the module (intellisense present)
Added a new webpart to the module (intellisense present)
added a user control to the project designer works and (intellisense present)
I believe that you should consider creating true server or visual web parts. This will have a harder learning curve but will pay with dividends in the future. You will be able to package and deploy your solution again or to another server/farm. Aspx pages can be added and manipulated by the dreaded SharePoint designer. In 2010 the theory is that those designer mods can be packaged and deployed.
I work in this environment every day and the best advice I can give is to embrace the SP object model and do 'it' the sharepoint way. Don't try to force SP to be something its not. :)
This is probably not the solution you are looking for but it's the best thing I found for SharePoint development.
In your solution, create 2 projects :
1 SharePoint Project (empty or not)
1 ASP.NET web application project
Develop all your UI (aspx pages, ascx controls, etc.) in your ASP.NET project and create post-build steps that will copy the pages and controls to the appropriate folders in your SharePoint solution.
That way, you will benefit from all the features of web development in visual studio and it will be very easy to deploy as well. It is a bit of a time investment at first, but it is well worth it if you have any considerable amount of logic to implement in your aspx pages.
This blog post documents what you need to do.
you can add an intellsense to pagelayouts by closing the page and simply reopen it from
file->openfile->your file page layout path
Or you can directly "Right Click" on the file you want to open from the Solution explorer and then select "Open" : you'll get the Intellisense !
Pros and cons of editing sharepoint master page in sharepoint designer or visual studio? Which one do you prefer
SharePoint Designer
Pro:
WYSIWYG editing
Very fast turaround Edit/save/test
Con:
No Version control
Cumbersome reuse/deployment
(Download/Upload)
Visual Studio
Pro:
Integration with Source Control
Deployment/Reuse via Feature/Solution framework
Con:
Pure source code editing
Cumbersome Edit/Deploy/Test cycle
SharePoint Designer & Visual Studio
My recommendation is to use SharePoint Designer to develop the master page on your development machine. Then save the MasterPage into a Visual Studio solution for deployment to Test/Production:
Pro:
WYSIWYG editing
Very fast turaround Edit/save/test
Integration with Source Control
Deployment/Reuse via Feature/Solution framework
Con:
You need both tools, but SharePoint designer is free and this is in general the most efficient way of developing for SharePoint. Make what you can using SPD and the Web UI, then save it into a Visual Studio Solution for version control/deployment
For the most part I agree with what Per Jakobsen answered above. ESPECIALLY for SharePoint 2007.
Additional comments on the Pros/Cons of SharePoint Designer 2010:
I have actually had very good experiences with using SharePoint Designer exclusively for most of the "front end" work. Meaning, anything that is not a Server Side Web Part...
Regarding the "Cons" listed above:
Source Control -
Setting up the SharePoint Version Controls for the document libraries that store the web pages you are working on does a fairly decent job of managing Source Control - which is handy when you are doing development work on the Production server. (see below)
Cumbersome reuse/deployment
Not sure what is being referred to here, but I THINK it is in regards to developing code in one place, and then deploying that to a production server.
With permissions set correctly users are not impacted by development work because they will see the pages/code that is checked in, approved and viewable.
While I would normally hesitate to operate on production directly, there are many scenarios with SharePoint that require this - especially if you are editing XSLT data directly, etc. (what comes to mind off the top of my head are references to List or Library GUIDs and other "variables" that will be different between servers)
Cheers!
Although I don't know why, SPD also changes your <%# Register ... %> tags: it strips any leading "~" from the src="~/_controltemplates/..." attribute. You need to manually add them back in before publishing.