Jul15
Categories: Deployment, Development, General, SharePoint, Tools, Visual Studio, VSeWSS
So Matt Smith of the Christchurch SharePoint User Group has organised a national tour for the various SPUGs that are active here in New Zealand.
I'll be talking in Auckland, Tauranga and Christchurch over the space of a week. The fine people in Tauranga are either doubly blessed or cursed as I'll be talking to both the SPUG and DNUG there.
The low down on the SPUG presentation:
Collaborative construction of custom SharePoint artifacts
See how business users, business analysts, developers and IT Pros can all come together to create new SharePoint artifacts for your business. In this session Gavin Barron will show how users from differing disciplines can all work together. Ensuring that an emerging business need is addressed quickly while following a number of SharePoint best practices. During this session Gavin will also discuss the development lifecycle as it exists in this context.
Presented by: Gavin Barron, Intergen Wellington
Intended Audience:
- Business Users
- Business Analysts
- Developers
- IT Professionals
The tour details:
Auckland: Wednesday, 23 July
Time: Drinks + Snacks from 5:15PM, Talk from 5:30PM to 6:30PM
Location: Level 7 Fronde House, 131 Queen Street
Tauranga: Thursday, 24 July
Time: Drinks + Snacks from 5:30PM, Talk from 6:00PM to 7:00PM
Location: EnvisionIT, Level 5 Westpac Building, 2 Devonport Road, Tauranga
Christchurch: Monday, 28 July
Time: Drinks + Snacks from 5:30PM, Talk from 6:00PM to 7:00PM
Location: Canterbury Innovation Incubator (CII), 200 Armagh Street (opposite Centennial Leisure Centre)
I'll post more on the Tauranga DNUG session later.
Jun20
Categories: Development, VSeWSS, SharePointChan has just announced that Paul Andrew is going to be visiting us here in Wellington, New Zealand and presenting to the SharePoint Users Group :o)
This special event will be held in Xero offices 5pm Friday 27 June 2008. Yes, it's a Friday, but as usual there will be pizza and drinks plus the chance to grill one of the Product Manager for the SharePoint team ;o)
I've worked with for Paul on a couple of projects that Intergen have done for Microsoft now. I'd say that the session that he is going to present will be focused on VSeWSS 1.2, this being the Visual Studio 2008 compatible version of VSeWSS 1.1.
Please register your interest by RSVP to kirkj@paradise.net.nz and wlgspug@sharepointservices.net.nz
Hope to see plenty of you there :o)
Jun10
Categories: VSeWSS, Visual Studio, SharePoint, Tools
May13
Categories: Development, SharePoint, VSeWSS, Visual StudioMicrosoft have just released the full version of the user guide for VseWSS 1.1.
Also, take a look at the authors ;o)
Mar12
Categories: Development, VSeWSS, Visual StudioSo, I have a project that I'm still working on that is using VSeWSS 1.0 project templates.
I just got bitten by an issue I knew about from prior experience :o\
With this version VSeWSS creates a file called solution.xml in the root project folder, this appears to be used as offline storage for the settings for the Visual Studio Project that are edited through the SharePoint Solution tab in the Project Properties page i.e. it's written to when you close the Visual Studio Solution. Cool, that seems to be a reasonable and valid approach.
The problem arrises when you put it under source control..... Now the file on disk is marked as read only. Now when you're closing the Visual Studio Solution the file that Visual Studio is trying to write to a read only file and can't, so the settings changes that you made are lost :o(
The work around? Simple, include the solution.xml file in the Visual Studio Project, check it out before you close the Visual Studio Solution using File > Close Solution, then check in the solution.xml file to share your changes with the rest of the team and you're golden! :o)
Mar12
Categories: Deployment, VSeWSS, SharePoint, DevelopmentOk, here at
Intergen we are working on the
VSeWSS 1.1 User Guide. As part of this we have to create code samples in both C# and VB.NET for all the code that we produce. No big deal really.
Except that when you attempt to deploy the second version of the code you get the message:
"This solution contains two assemblies with the same name, or the SharePoint server already has an assembly with the specified name."
Huh? What's going on here was my first reaction. After applying a little thought to it I realised that there was a solution package added and deployed to the SharePoint server that had same name as the one I was attempting to deploy. This solution package also contained assemblies of the exact same names as those that I was trying to deploy this time, in my case the C# version had been done first.
So knowing a little of what happens at pacaking and deployment time I opened up a file browser and looked in the bin\debug folder of the current project. Had the packaging worked I would have found a .wsp file and a setut.bat file, neither of these was presesnt so the check that throws up this message must be run prior to packaging the .wsp file for our VB.NET version.
Luckily I had the setup.bat file from the C# version! So I just ran setup.bat /uniinstall which will remove the solution package for which it was generated.
However, should you not have that file, it's still pretty easy to get arround this problem, it just requires a little stsadm fu!
Open up cmd and run these commands:
C:
cd "\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"
stsadm -o enumsolutions
Now examine the XML output to see if you have a .wsp in that list that matches the name of the .wsp that will be created and deployed by VSeWSS for the project that you're working on. If you do you're in business!
stsadm -o retractsolution -name <Solution name> -url <virtual server url> -local
stsadm -o deletesolution -name <Solution name>
Note: do this with care! If the solution you remove is not on that you've developed then you might break other features in your SharePoint instance.
Mar5
Categories: SharePoint, Visual Studio, VSeWSS
So I'm using VSeWSS on a project at the moment and have just discovered something that I should share.
The setup.bat file that is generated to deploy the solution (.wsp) file to your development box is not perfect for use when you're going to PROD. I've just found the first of the short commings.
It's this line:
echo Deploying solution %PackageName% ...
"%SPAdminTool%" -o deploysolution -name "%PackageName%" -local -allowGacDeployment -url %TargetWebUrl%
The use of the -local argument prevents this solution from propagating out to the other servers in the farm. So no biggie if you're only running a single front end node, but a headache if you have a multi server environment....