You can download Adobe Reader for mobile devices for free. Just run the installer from your PC and use ActiveSync to push the installation to your mobile device (this should work automatically). Don’t forget to read the Adobe Reader for Pocket PC FAQ.
Links you should check out for some inspiration if you are thinking about SharePoint Governance:
Lastweek I installed Windows Server 2008 from MSDN subscriber downloads – unfortunately when I tried to activate it – I got an error telling “A problem occurred when Windows tried to activate. Error code 0x8007232B. For a possible resolution, click more information.” When you click the more information link you get "Code 0x9007232B - DNS name does not exist". Luckily I found the workaround - Activate Windows Server 2008 RTM (MSDN subscriberd downloads version) – just reenter the license key and Windows will automatically activate.
When you need to run 64-bit virtual environments on you dev machine – you will not be able to use Virtual PC. So most of the time I’ll use VMWare Workstation. A setting you will need to take a look at is how VMWare will use the allocated memory – go to Edit>Preferences and select the Memory tab.
Microsoft just released some sneak preview content about SharePOint 2010 . Definitely take a look at SharePoint 2010 - Overview Sneak Peek Video – by Thomas Rizzo.
Some key takeaways:
It seems that the download location of the SCOM management packs fro SharePoint have changed:
Today my smartphone started struggling with a lack of free storage. After searching for large files using storage memory – I found a file which is called mms_handler.txt which seems to be a log file of some sort. You can apparently safely delete it.
Just stumbled upon this project from Microsoft Research - KODU
Kodu is a new visual programming language made specifically for creating games. It is designed to be accessible for children and enjoyable for anyone. The programming environment runs on the Xbox, allowing rapid design iteration using only a game controller for input.
So why do you need to get access to source code of custom built SharePoint components? What about 3d party ISVs versus System Integrators?
One thing to note is that I make a distinction between system integrators/consultancy firms and firms whose main target is to build specific SharePoint products. I do not expect that 3d party SharePoint ISV’s will release source code but I also think this is not that much of a problem since their products are widely deployed (ask for references!!!) and they know that a bad rep would kill their business. Therefore they probably have a stringent quality process for building SharePoint addons.
If your custom built solution is procured as a product purchase it is very rare that you get access to the source code and even if you do – you have to make sure that he source code does not get into the wrong hands.
If the custom built solution is procured as part of a works made for hire or services engagement (which is mostly the case with system integrators or consultancy firms), the source code is mostly provided – but not always.
Sourcecode keeps SI’s honest
Access to source code gives you additional flexiblity. If you need a change to your custom built solution you might have the option to do it yourself instead of reverting back to the System Integration. If you have access to the source code, then any SI can make the change. It keeps everyone honest… and it is better from a business continuity perspective. You probably want to protect your investments.
It probably is very disturbing when you notice that you can’t upgrade your platform since you have a lock-in from a custom built solution tied to a specific system integrator or consultancy firm.
Review deployed sourcecode
A custom build solution deployed on SharePoint can have the ability to impersonate to any other account without their passwords – take a look at Elevation of Privilege for some background info. You cannot be absolutely sure that they are not doing this, unless you have the ability to review the source code from a technical perspective.
If you have access to the code it is also easier to validate the deliverable (the code) in terms of what you have agreed upon – this is what I call review source code from a functional perspective.
If you do not care if SharePoint code runs as fully trusted and you do not attempt to enforce partially trusted scenario’s – you probably don’t need the source code. Reviewing source code (and this is certainly the case for SharePoint) is not for the faint of heart and requires a lot of effort.
Best practice – do your own builds
If you are planning to run business critical applications on top of SharePoint make sure that you actually do the builds of the source code yourself. You might be in for a surprise when you notice that the source code built does not equal the deployed assmemblies because some extra code was added in the dll’s which are deployed on your server.
If you are a customer who works with a system integrator or consultancy firm you might even ask access to parts of their code repository. This way you can use this code directly and even see actual progress of your project at any time without the delay of having to send an e-mail every time. Take for example a look at Using Team Foundation Server to develop Custom SharePoint Products and Technologies applications
Look at the contract
Common sense dictates that you have to look at contracts that you sign – and this is also the case for software project contracts. Make sure that you look at the small print of a contract. Look if it is not explicitly stated that you do NOT get access to the source code. Most of the time, the SI will give you a non-exclusive license to use the source code internally. You get access but you do not own the code. The SI will probably retain the rights to reuse, package, deploy, sell, etc… the source code and all derivative works.
Some SI’s work with third party source code escrow agents where the source code is kept (under escrow) and is only released under certain conditions – for example when the supplier goes out of business (One of the players is Escrow Europe which also has an affiliate in Belgium - another one is Merak)
Remark: The views expressed here are personal and do not necessarily reflect the views of my employer.
Because of it’s viral nature a SharePoint deployment without any control has a high risk of becoming total chaos. Yesterday SharePointGovernance.org launched to help you effectively manage your SharePoint environment. I will actively work with some peers on SharePointGovernance.org to share some of the do’s and don’ts with regards to share. Hope to see you there…
1. Stick to the product if you can. SharePoint provides a lot of functionality out of the box - focus on these quick wins and don't immediately switch over to Visual Studio and start writing code.
2. Built to last SharePoint projects are in continuous evolution so you need to develop in such a way that it is easy to evolve and to extend. Take a look at site definitions vs site templates for example.
3. Do not GAC every web part you develop. By the way, there are number of SharePoint development artifacts which you need to add to the Global Assembly Cache (GAC) such as receivers -feature receivers as well as other event receivers - timer jobs and workflow assemblies.
4. Keep your custom site definitions as minimal as possible. A long debate started after Joel's post on the topic - Do you really need a site definition . They are nothing more than a "skeleton" for attaching programmatic elements in the form of features and should be deployed as solution packages.
5. Do not touch the production server's file system. Yes, if you need to deploy something you really need to wrap it up as a SharePoint solution file (wsp). Check out Creating a SharePoint Solution Package in Windows SharePoint Services 3.0 as well as my own post from a while ago - WSP - SharePoint Solution Files. Don't forget to take a look at WSPBuilder
6. Features are your friend . Features can be added to sites as needed. You can even force their deployment through stapling them to existing Site Definitions. Features can be activated, deactivated, and even upgraded, on existing sites.
7. Thou shall not use Full trust in vain. Changing the trust level in the web.config is just stupid for anything other than debugging. So learn to use SharePoint Code Access Security policy files.
8. Stay out of the database. The SharePoint database schema should not be altered in any fashion or you will lose all support in case of an incident. KB841057 - Support for changes to the databases that are used by Office Server products and by Windows SharePoint Services. I think it is also safe to not directly read from the database – SharePoint provides you with multiple methods to do exactly what you need – stsadm, the object model, web services or WSS RPCs so there’s no need to read directly from the database.
9. Use different development, build, test, staging, and production environments. Take a look at the SharePoint application life cycle from the P&P SharePoint guidance. If you are unsure about the why and how.
10. Be your admins friend You can make deploying a SharePoint solution very easy for your admins using SharePoint solution packages, together with powershell and/or stsadm extensions. Or can make his life hell – remember this quote from JThake - “Mr SharePoint Solution meets Mr XCopy in a bar and kicks the living sh*t out of him” (Jthake)
PS These commandments are not listed in order of importance… if you have some other ones – please add a comment.
A quite unfortunately quirck of SharePoint SP2 was that after you installed it, the product expiration date was activated incorrectly (For more details check out KB 971620 )
The SharePoint team blog also states that an update of SP2 will be provided in the coming weeks.
