This site is a self-contained low down on what's going on in my life, what I'm working on, what I'm thinking about, and how I'm feeling about life in general.

Thursday, 31 July 2008

 

This article is aimed at those developers who've developed their own SharePoint 2007 webparts in Visual Studio using the wss sdk and want to deploy them to a different server.

1. Build it

The first step is to do a standard Visual Studio deployment of your webpart (F5 or the play button). Once this has happened go to the project folder, then the bin > debug folder.


2. Take it

In here you should have a file along the lines of my_projects.wsp. Take this file and copy it to a folder on one of the web front ends you are deploying on.


3. Script it

Next you need to create two files in the same folder ideally as your .wsp file.

Create a new text document and call it DeploySolution.cmd, then add the following lines to it, replacing my_solution.wsp with your solution name.

 

@setlocal
@pushd.

@set PATH=C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN;%PATH% @cd %~dp0

stsadm.exe -o addsolution -filename my_solution.wsp
stsadm.exe -o deploysolution -name my_solution.wsp -allcontenturls -allowGacDeployment -immediate
stsadm.exe -o execadmsvcjobs

@pause
@popd
@endlocal

 

Once you have done that, create another text document and call it RetractSolution.cmd, then add the following lines to it, again, replacing my_solution.wsp with your solution name.

 

@setlocal
@pushd.

@set PATH=C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN;%PATH% @cd %~dp0

stsadm.exe -o retractsolution -name my_solution.wsp -local -allcontenturls -immediate
stsadm.exe -o deletesolution -name my_solution.wsp
stsadm.exe -o execadmsvcjobs

@pause
@popd
@endlocal

 

Use the first script to deploy your solutions on the server. If you need to update the solution, first use the retract solution script, then re-run the deployment script.

Once you've run the script, you'll most likely have to go into Site Settings > Site Collection Features and turn on the webpart.



Tags: Web SharePoint Webpart Part 2007 Deploy Load Send Dwp Script stsadm

Thursday, 19 June 2008

I’ve been trying to create two webparts that communicate with each other in SharePoint. Looking around the web there are a number of good examples of how to create an asp.net 2.0 webpart that communicates with another but there are a couple of things that they don’t tell you.

Develop your webparts in one project

If you want your webparts to be able to talk to each other, you have to develop them in the same project in Visual Studio, otherwise they won’t compile. Sounds obvious enough but no-one ever actually says to do this.

Once you’ve built the provider webpart, simply add a new webpart into the solution explorer and off you go.

Linking the webparts

Another thing that is never covered for SharePoint is how to link the webparts once they’ve been developed. Firstly, click edit page, and then click the edit button on either the provider or the consumer webpart.

Screenshot of sharepoints communication options

From here you will see connections, select send ... to, or get ... from, depending on which webpart you’re looking at. Once this relationship has been established, your webparts should communicate perfectly.



Tags: Microsoft Web ASP.NET SharePoint Webpart Part Communication Communicate Link 2007 Develop

Monday, 21 April 2008

Web standards is a passion of mine. They are the guidelines set down for a document type, and should be followed. Being a devout standards follower can bring you kudos and appreciation, but your efforts may be let down by the web browser used to view the site.

Poor support for web standards in Internet Explorer mainly, and older versions of Safari, amongst others, means that your site may loose much of it's shape and pizzaz.

Until now, the challenge of the web designer has been to tailor their styles and code to be cross-browser compatible. Ultimately, you may have to reign back some of your design and functionality, sacrificing the overall product, but what if the situation was turned upside down.

Imagine if some of the biggest websites started blocking browsers that would not display their site correctly? It's not unheard of for a site to carry a disclaimer that it will only work properly in Internet Explorer, but you just do not see complete blocking at browser level, and because of this, there is no incentive for Microsoft to release patches for their slightly older browsers (which still dominate the browser demographic).

This type of motion would have to be started by a major site, one that could sway enough opinion and also encourage more users to upgrade, faster than if the smaller sites embarked on such a mission.

Legally, the site ultimately has impunity from prosecution on the grounds of discrimination because the browsers are not technically capable of displaying the content correctly and consitently, and therefore can be blcoked from viewing the content.

Morally, there is always going to be the desire to be open to all, but I think a day will come when major sites will force a browser upgrade before granting access.

Technically, there is a level of satisfaction derived from creating a site that renders near identically on multiple browsers, but the time it takes to achieve this compatibility, and time is money.



Tags: Standards Safari Web_Standards Browser Internet Explorer Leverage Web Giant Accessibility Blocking Discrimination
Featured Articles
Recent Articles