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?
I am new to SharePoint, I am using SP 2010. I am asp.net developer but I don't understand if I have web.config under 80, so what are those web.config files under 14 folder, can you briefly discuss it?
I found two so far, There is one under 14\Templates\Layouts and under 14\CONFIG
Thanks
SharePoint development is similar to ASP.NET development but there are some major differences you need to be aware of. One is the use of Web.config to store application settings.
I wrote a blog post with links to several resources to help new SharePoint developers get started: Getting Started with SharePoint 2010 Development–Links and Resources
I suggest you start by watching the SharePoint for ASP.NET Developers talk to get an idea of the SharePoint architecture and development/deployment model.
You will find a lot more in 14 hive :) They are there because they are web.config files for different parts of the entire sharepoint application pages. For example the one in "14\layouts\" is for general application pages, site settings, regional settings, ... for instance. the one in the 14\layouts\admin is for centeral administration pages.
I'm working on remolding my companies current exsisting Sharepoint site. I installed the SP ZAP Slideshow webpart and went to the sharepoint site to insert it, and absolutely no webparts were listed. I went into the provided Sharepoint 2010 central administration and realized that everything seems to be listed as
//usmvwc0wtf1srv.ww005.work.net/sitepages/
When the website were hosting, and it should be listing is
//usmvwc0wtf1srv.ww005.work.net/sites/
I went to the /sitepages website and all the webparts exsisted and worked, however i need to get them working on the /sites page. Is there some way to switch it so it will not default all the webparts and content i'm uploading to the wrong page? I feel as though the wrong default page is listed? sorry new to all this!
Web Parts, which you see listed and are able to insert on a page when you edit it, come from the Web Part Gallery in the site collection. They are usually installed to the gallery when you activate their site collection-scope feature. Check what features you didn't activate in the new site collection - I suspect that one of them is responsible for the installation of Web Parts you are looking for. (The scope of the feature can be site collection or site - check both.)
I am doing my final year project and have decided to make a website in asp.net. For that I'll be using Micrsoft Visual Studio 2008. I'm making a Real ESTATE properties website. I want to know how to localize or create new posts in asp.net( like in WORDPRESS) and also when I hit SEARCH it should search for the desired keyword or the searched post.
If post is not possible then it should display pages...
Asp.net is just the language not the CMS. You have to install a CMS for blogs such as dotnetnuke or BlogEngine.net
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have been asked to develop some usercontrols in ASP.NET that will at a later point be pulled into a SharePoint site as web parts. I am new to SharePoint and will not have access to a SharePoint server during the time I need to prototype these parts.
Does anyone know of any reasons that this approach will not work?
If this approach is not recommended, what would other options be?
Any suggestions on a resource/tutorial on what to consider when developing an ASP.NET web part with SharePoint in mind?
Thanks
Edit: 12/31/2008
I finally marked an answer to this one. It took me a while to realize that going the SharePoint route right away, though painful at first, is the best way to go about it. The free VPC image makes getting set up to develop relatively painless.
While you can, as I did, develop web parts in ASP.NET without SharePoint, when it comes to developing and deploying SharePoint applications you haven't learned a thing, only pushed the learning curve off into a time when you think you are done, (and have probably informed stakeholders to that effect). To delay the SharePoint learning curve doesn't do you or your project any favors, and your final product will better for the expertise you gain along the way.
ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.
The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.
Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:
If you can put everything inside of a single assembly, deployment will be easier
try to put everything you need into the DLL's that are deployed to SharePoint
use assembly resources to embed JS, CSS, and image files if needed
Strong name the assembly you are building
Most SharePoint deployments end up in the GAC and a strong name will be required
Here is a relevant blog post; Developing Basic Web Parts in SharePoint 2007
If it's a very short-term thing, Microsoft has a time-limited WSS evaluation VPC image:
WSS3 SP1 Developer Evaluation VPC image
That will get you started if you don't have time/resources to set up your own VPC image right now.
I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.
Setting up my machine to develop for Sharepoint took me a couple of days.
See http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
Build and test the control as you would for a typical .net web site.
Solution 1 = the controls
Solution 2 = dummy website to host the controls.
Deployment on Sharepoint:
You'll need to sign the controls.
Drop the signed DLL into the GAC on the sharepoint server (Windows/assembly)
Mark the control as safe in the virtual server root web.config on the sharepoint site.
i.e.
<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />
Register the component in your sharepoint page:
<%# Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>
Use the control:
<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>
If you need to replace the control using the same version number, then you'll need to recycle the app pool to reload.
If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.
you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.
You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here
Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.
If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.
Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.