Now it's my turn to ask this question..
I've been reading about setting up an umbraco project in VS2012 but i really don't know if im doing it worng, or if it's just not possible..
Is it possible to setup an umbraco project in VS2012 with ability to add templates, and documenttypes and create sites and more with VS2012 without using the umbraco admin tool? :-)
Yes, in fact, only 2 minutes ago I finished checking in a brand new project, a VS2012 solution housing an Umbraco v6 website.
My solution/directory setup is particular, and no doubt yours is too, but the bottom line is that the Umbraco is just an ASP.NET website, so you can add it to a solution using thew "Add existing website" option, to the root or subdirectory of your will.
Then you can use the Solution Explorer to edit files such as those in the css, masterPages, and macroScripts folder etc.
One note of caution would be this. When using 'Umbraco scripts' (i.e. Razor scripting files and such) then, when created in the Umbraco UI, a calling Macro is also created (by default, though there is an opt-out) and (historically) some database goings-on, and so in the case of scripts, I think it's always wise to initially create them using the Umbraco UI.
Other than that, are you having a specific problem, as I don't see you point one out?
Related
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 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 !
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.
Here's the scenario
I created a Site which in I used custom lists, webparts, custom developed webparts, workflows et cetera. You can see the site as an application.
What I am trying to do is to create a solution package which holds everything I build in that site so that I can give the solution file to an sharepoint administrator who can install the solution to his sharepoint environment.
For example look at the free application templates you can download from MSDN, I am trying to achieve the same as they did. One solution file to hold them all!
Any idea's?
Cheers!
Get STSDev and SharePoint Manager. STSDev is goog for creating the solution you want and SharePoint Manager can be used to get the SchemaXML from the customisations you have already created.
You will need to package up the webparts and everything. Unfortunately, this is a pretty hefty learning curve, so expect to do a lot of reading on this subject and some experimentation. However, this is time well spent as a solution is the "only" way to release a custom site definition.
Workflows created using SPD are not portable across sites - they will have to be recreated. As a result, Nathan's solution is probably going to be the only way to go.
Export the site as a template and include all the content. The workflows will point at the old site and will need to be updated manually, I believe. Everything else should work.
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->