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 !
Related
Is there any way that I can create a template within forms to utilize for every user in the company?
For instance; let's say I have the Sales Order Screen (SO301000) and the Document Detail grid configured in certain way, that display different amount of columns than the default (either more or less columns).
For each user I want to use this template (and all the ones created) that I will apply when I add the new user.
I'l appreciate any guidance and help.
EDIT:
I provided answer for Form element ASP template below. Although reading your question again I think what you're trying to do would be more along the lines of automating grid column configuration. We call this feature Default Table Layout.
There's a feature request for it here:
https://feedback.acumatica.com/ideas/ACU-I-415
The feature has been shipped in version 2017R2 and is documented here:
https://help.acumatica.com/(W(1))/Main?ScreenId=ShowWiki&pageid=30f3229f-20f1-4055-9c03-e0fe3b37080d
Image copy of documentation page:
For ASP Form templates
There are two ways to work with customizations in Acumatica:
As a Customization Project, everything is done directly in Acumatica
instance through the web browser using the Customization Project Editor.
As an extension library (DLL file) compiled in Visual Studio which is then included in the FILES section of a Customization Project.
For method 1, I believe creating custom templates would be a bit of a hack and would not be officially supported, if someone knows otherwise please chime in.
For method 2, we ship the Visual Studio templates with the Acumatica Configuration Wizard (Acumatica ERP Installer).
Those templates are in the following folder:
My Documents\Visual Studio 20XX\Templates\ItemTemplates\Visual C#
The templates will be available for ASP.NET solution only. You can open Acumatica Instance Website as a solution if the website is already deployed:
When you open Add New Item dialog:
The Acumatica Templates will be available:
Those are standard Visual Studio templates so you can copy and re-use them to create your own. Microsoft documentation for creating user template applies and you can follow their guidelines. Note that working with Visual Studio and creating your own template is somewhat less user friendly than using Acumatica Customization Project Editor.
Acumatica T100 covers using Visual Studio to create customizations and would be a good starting point to learn the techniques involved:
https://openuni.acumatica.com/courses/development/t100-introduction-to-acumatica-framework/
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...
Apologies if this has been answered, but I could not find a similar question:
I am developing a webpart for MOSS 2007. I am using WSPBuilder to built a visual webpart (ascx) and everything works fine, but the development/debug cycle is just painfully slow, so I'd like to know if it is possible (without being too painful) to develop the user control faster using an .Net Web Application project with all of the nice F5 debugging, then import the final product into my SharePoint visual webpart.
The user control interacts with a LOB system (SQL) and does not reference the SharePoint API at all. (The reason I am building this as a webpart is because I don't need another web app to run this one page, so putting it into a webpart on a new webpart page on my existing site is the best solution IMO.) I would obviously need to import (reference?) my data access classes into my "temp" web app, but think that would not be too much trouble.
I realize this will be extra effort to get this set up, but am thinking the payoff will be reduced development time of the actual user control using a little web application vs having to use the compile/build WSP/deploy WSP/reset ISS/test/make a change/repeat cycle that MOSS requires. (I guess SP2010/VS2010 has spoiled me with the native SharePoint tools available.)
Update:
I have successfully built a simple web app with one page and loaded up my UC on the page. (I had to comment out all of the Sharepoint Import and register statements that WSP Builder added to the UC for me when I created the webpart.) I added references to my utility classes (which I left in the obj\Debug folder in the original SharePoint project). It took me a while tinkering with everything to get it to work, but the steps ended up being pretty simple and I think I can replicate the steps quickly for future projects. Once it was set up, I was able to rapidly design the UC and build in the UC functionality using the typical F5 debug cycle. Unless someone can show me why this is not a good idea, I plan to repeat this for future projects! Thanks to everyone for thier input.
.
Update 2
Well, I am not sure what I did but moving the UC back into SharePoint proved to be troublesome. The first time I did it, I spent several hours getting it to work in SharePoint, making me question whether it was worth it. However, I am stubborn and tried it again. This time, I only copied and pasted the markup below the "header section" (the part with all of the <%# . . . %> statements) in the ascx file and everything went perfectly. I think I must have changed something inadvertantly the first time. I think I will continue this pattern as it is so much faster to build and test the UC in an ASP.NET web app. (Again, this only works if you are not referencing the Sharepoint API anywhere in the UC.)
The answer here is the SmartPart. It is perfect for just the scenario you are describing. Very easy to create a Usercontrol using "vanilla" ASP.NET and have it work as a webpart in SharePoint. I've outlined the steps to migrate from ASP.NET webpage to statically bound SmartPart on my blog.
What you intend to achieve is surely a nice idea.
Just remember to strong name your user control, drop it in your Server's GAC, update SafeControls section of your SharePoint 80's web.config.
All these setps are one off, after each successive builds (of your web control), you have to just deploy the control (used forcede deploy) in GAC and reset IIS.
You can add this control to toolbox in VS by selecting 'Choose Items' and selecting ther assembly you just deployed.
In addition you can create a test ASP.NET page to test the functionality of your control.
I'm trying to figure out if it is possible to create a custom document library template for SharePoint 2010. When a user clicks on the Libraries link on the quick launch menu of a new SharePoint site, and then clicks the Create button, the Create dialog is launched.
I know this dialog window hosts a Silverlight control, but obviously there is a way to create custom template types in this window. There is even a category that is called Blank & Custom. I've tried copying and modifying the DocumentLibrary feature located in the following location - C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES, but that didn't seem to work.
Thanks for reading, I'm sure the answer is obvious but I've been stumbling over Google and MSDN all morning trying to figure this out but I haven't had any luck.
Well, unfortunately the answer is not that obvious. You'll have to create a new List Definition (a document library is actually a list). For that there are several ways, but as a developer, I guess the most common way is to do that through Visual Studio.
A basic tutorial that will guide you through the steps can be found here:
http://msdn.microsoft.com/en-us/library/ms466023.aspx
After you deploy your solution, a new list template (or document library, depending what you created) will show up in the dialog.
Yes, it is not that obvious at all.
Most of the Microsoft documentation is now based on using Visual Studio 2010 and are more focused on the lists than on the document libraries.
By the way, as told by Erwin, document libraries in SharePoint 2010 seems to have become lists, but the lack of documentation regarding the creation of custom lists remains anyway, so after having perform some successful trials I have decided to publish a step by step guide.
Sharepoint 2010 custom ducoment library
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.