I have team members that need to be able to checkin VBA modules/classes created in Excel 2007/2010.
I want to be able to use some TFS functionality, ideally from within the VBA IDE.
I don't want to checkin Excel files as artefacts. Ive seen the MSSCCI provider download from MS.
I don't think in this case the Windows shell extensions from the Power Toys helps because I don't want to have to create an additional process for developers to export and/or import class & module files from their work in VBA project maintenance.
Question: Can someone provide a way to use the MSSCCI provider with Excel 2007 (or even Excel 2010 only)? Do you think this would only be possible with custom VBA addin?
Update:
I've thought about using an approach such as making a custom VBA addin and adding some commands that make basic calls to the TFS client object model.
Just found this post from Codeproject from another question this time looking for the same thing but for SVN rather than TFS.
There is a Visual SorceSafe provider for VBE that comes with Office XP Developer. I used it for many years and still have it installed. It does what you want, but using VSS and not TFS.
Note that the product is not supported, but VBA/VBE has not changed since Office 2000. I used the provider for two years for Excel 2003 development with no problems.
I seem to remember recently an article describing how you can use VBA/VSS with the extra benefit of having the code also "posted" to TFS. Since I no longer professionally code in VBA/VSS, I didn't have a need for the article, but did find the topic interesting.
Office XP Developer has a few other tools that make it worth the time to install.
Access Source Code Control and Team Foundation Server
Today's guest writer is Mike Sullivan - a tester on the Access team
With the release of Visual Studio Team System 2008, we've recently received questions from several customers regarding whether or not Team Foundation Server (TFS) can act as a source code control provider for the Access source code control (SCC) component. The answer is yes!
Although many folks refer to Access’ source code control component as “SourceSafe integration,” that only tells part of the story. SCC integration within Access is fully compatible with any provider that implements the Microsoft Source Code Control Interface (MSSCCI). Although Visual SourceSafe is one of the more widely used MSSCCI providers, there are several other products that implement this interface, including Team Foundation Server 2005 & 2008 as well as IBM ClearCase.
However, MSSCCI support in Team Foundation Server is not native and requires an additional add-in available for download:
MSSCCI Add-in for Team Foundation Server 2005 http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en
MSSCCI Add-in for Team Foundation Server 2008 http://www.microsoft.com/downloads/details.aspx?familyid=faeb7636-644e-451a-90d4-7947217da0e7&displaylang=en
Of course, to enable SCC functionality from within Access, you’ll also need the Source Code Control add-in. This shipped as a free download as a part of the Access Developer Extensions for Access 2007 and as a separate free add-in for Access 2003:
Access 2007 Developer Extensions http://www.microsoft.com/downloads/details.aspx?FamilyId=D96A8358-ECE4-4BEE-A844-F81856DCEB67&displaylang=en
Access 2003 Source Code Control Add-in http://www.microsoft.com/downloads/details.aspx?familyid=2ea45ff4-a916-48c5-8f84-44b91fa774bc&displaylang=en
If you’re interested in taking this configuration for a whirl, you might want to download the Team Foundation Server Virtual PC image that has been made available by the Visual Studio team. Included on this virtual PC are copies of Visual Studio Team System 2008 and Office 2007 Enterprise SP1 (though Access is not installed by default on this image – you’ll need to go to Add/Remove programs within Control panel and launch setup to install Access). This trial image is good through December 31, 2008.
To get the Virtual PC image working, you’ll also need to install the Access Developer Extensions (the MSSCCI add-in is preinstalled). Since VSS is the default MSSCCI provider on the machine, you’ll need to tweak a registry key to get Access to use Team Foundation instead:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\SOURCECODECONTROLPROVIDER
Key: ProviderRegKey
Value: SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider
Hopefully those of you curious about support for TFS have had your questions answered!
Related
Since Visual Studio 2010 Crystal Reports are no longer part of Visual Studio.
I'm using Visual Studio 2012 Professional and despite checking various sources I cannot reliably determine whether I can
freely download and use Crystal Reports Developer version for development of commercial applications in Visual Studio 2012
freely distribute and install Crystal Reports Runtime for running apps (developed above) at clients
In other words, do I need to purchase a license or not? Do clients need purchase their licenses, too?
(Besides your answer, providing link to sources of information will be appreciated.)
FYI - For obtaining Crystal Reports, there is a great resource containing all versions and package types, but still leaving me without the answer.
Yes, basic solutions, that allow a developer to generate and deploy reports, are free.
Advanced solutions, that allow end user to create, edit and share reports are not free.
It is free the IDE to be used with Visual Studio; stand alone full IDE is not free
Crystal Reports Runtime for running apps is free. SAP Crystal Server is not free.
EDIT
Look at this article: How do you spell confusion; CR for VS, Crystal 2011, BI 4.x and the .NET SDKs
And "Crystal Reports for Visual Studio 2010" (CRVS2010) is born. Note that this version, follows in the footsteps of CR 10.5; it only works in the VS 2010 IDE. E.g.; it is not a stand alone executable like CR XI R2 or CR 2008. CRVS 2010 has both 32 bit and 64 bit runtime. And it has the Crystal Reports SDK for .NET as well as the InProc RAS SDK. And it's FREE(!).
It seems that Crystal Reports licensing depends on many factors. There is a blog from an SAP employee: "SAP Crystal Licensing for Humans" which puts the information together and covers most cases. The entire simplified licensing whitepaper referred there has 20 pages. Currently the document is up-to-date also for 2013 releases.
Based on the above document (esp. page 4) the answer is that
SAP Crystal Reports for Visual Studio is free if Crystal Reports is used
internally in company (external users can also access, but no access fee can be charged to them)
-or-
with runtime engine deployed only on client machines, i.e. all report processing is done locally on client machine. Also no parallel access to such a client runtime is allowed (also including Citrix or Remote Desktop usage).
For additional information, please check that document.
Please see this post and the licensing information from SAP here to answer your questions.
Basically the answer to both questions is "Yes".
You can download the developer version here.
I know there are so many questions and articles on this topic and I have searched hours and hours on the Internet so far, but I still couldn’t find the right answer for my question. I was assigned the task to investigate the development environment for SharePoint web parts by my company. The money is not an issue but it must be the proper way to do it.
Here is my ideal plan: at developer desktop, install VS2005/2008 (it is already installed), VS2005/2008 Extension for SharePoint and WSPBuilder. It is also installed a Virtual Machine and the VM runs windows server 2003/2008. WSS3.0 and SQL Express 2005/2008 will be also installed on VM.
Developer’s desktop is a web parts development environment. Developers use VS to develop the SharePoint web parts and then run the WSPBuilder, it will deploy the web parts into the SharePoint testing environment on VM. So the VM is just a SharePoint testing environment.
It looks like a good idea, however, it doesn’t work. Why? Because VS extension can't be installed on developer’s desktop as it doesn’t have WSS3.0 installed!
I definitely don’t want to install the VS on the VM, because our developer desktop has installed VS and we don’t need to have 2 VS licences for 1 developer.
Any idea what is the best way to set up the development environment for SharePoint web parts?
Thank you in advance.
You won't be able to develop for SharePoint (WSS 3.0) unless your development environment includes an installation of at least WSS. In general, development is done on a Windows Server 2003 Virtual Machine (Visual Studio is installed directly on this machine). However, SharePoint can be installed on Windows Vista and Windows 7 machines, so your development machine may be able to host SharePoint itself, but it is far easier to do this on a VM.
My SharePoint development VM has the following installed:
Windows Server 2003 R2
SharePoint 2007 (Including SQL 2005)
Visual Studio 2008
Visual Studio Tools for Office
Office Server SDK
Visual Studio Extensions for WSS 1.3
Obviously you can use WSPBuilder instead, but I much prefer VSSWSS 1.3, but that is developer preference.
I believe (should be verified with Microsoft) that the licensing for Visual Studio can be extended to Virtual Machines when used by the same developer (depending on your agreement).
An alternative for you which may or may not work depending on your priorities.
Install Visual Studio 2010 and SharePoint 2010 Foundation to your development server.
Grab a copy of Microsoft.SharePoint.dll from a SharePoint 2007 server.
Use VS2010's tools to develop a web part but manually change the reference to the 2007 dll's (+ also see "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project") so you are outputing a 2007 compatible web part.
When you delploy your 2007 web part to your local 2010 server it will just work (as its backwardly compatible)
When you deploy your 2007 web part to your test/qa/production servers it will work too.
Advantages
You're working with latest greatest
version of VS and the sharepoint
tooling so you get one click deploy,
automatic creation of WSP packages
etc. Nothing against WSP Builder etc (they are great) but my moneys on vs2010 sharepoint extensions for the future.
You're ready if/when your
company moves to 2010.
You're developing on a Windows 7 machine, not a 2003/2008 server and or a VM so this has advantages for licensing, speed and ease of use (dual monitor support from VS running on a VM?)
Edit - to deploy web parts to other servers you create a .wsp package and then deploy via STSSADM or another tool (SharePoint solution installer or other admin tools).
I haven't used VSSWSS or WSPBuilder. I've always used STSDEV for SharePoint 2007. And I've always used Windows XP to do it. I don't know if VSSWSS and WSPBuilder act the same, but, as Ryan was saying, I copy whatever SharePoint DLLs I need from a SharePoint 2007 server into a Solution Folder in my Visual Studio solution. I then select Add Reference in my project and browse to the DLL.
In four years, I've never had any problems with this method. The solution packages build just fine and work on any SharePoint server. I lose the option to debug, but I'd rather stay on my machine than go into a VM or Remote Desktop.
Can Sharepoint apps be developed in a Visual Studio 2010 dev box only or does the dev box need to connect to a Sharepoint server? Can the Sharepoint Server be a stand alone machine (no domain controller between the two machines)?
The best practise for SharePoint development is to use a virtual server that contains the SharePoint install itself (and a copy of the portal you're working with), because assuming you are programming directly against the SP API, you will need to be executing your code on the machine that contains the Sharepoint installation itself.
You can program against SharePoint from a non-SharePoint machine through the use of the standard set of SharePoint web services provided, and you can of course create your own services (again sitting on the SP box/VM) to interrogate too. The catch to this approach is that you'll be dealing with return types that are primitive or XML based and you won't have the luxury of SP objects, for example SPUser, SPSite, etc, but for simple query operations at least this is not a bad approach.
IMHO, however, you've far greater flexbility programming against the API itself (Microsoft.Sharepoint.dll) so I'd advise you to get a VM going with all the necessary installs. Yes, it's a pain and time-consuming to set up, but well worth it.
As for Stand-alone options: SharePoint 2007 is not supported on anything non-server in terms of OS, so you'll need something like Server 2008 in order for it to work. SharePoint 2010, however, whilst claiming to only work on Server 2008, can actually work on Windows 7 (Pro and above) with a few hacks. You also have the benefit of 'sandbox' feature deployment in 2010, where you don't in 2007, meaning dev work is more cleanly isolated and less of a risk to a farm as a whole.
Good luck!
You can develop for SharePoint 2010 using VS 2010 using a stand alone setup - this is supported by Microsoft and very much recomended. Infact most of the tools built into VS2010 that will make your life significantly easier will only work with a local copy of SharePoint 2010.
MSDN - Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7...
Yes, if you have Windows 7 or Vista (you need WAS - Windows Activation Services). We have tried it but found that it was better to develop on a Windows 2008 with your own AD.
It will depend on what you are developing, for webparts you will not notice the difference. You will notice the difference when working on the security part og the app.
Sahil Maliks book has a whole chapter on the different options.
you can do sharepoint development by copying certain dlls to your local enviroment but to my understanding this is unsupported and the recommended practice is to use a virtual machine or development on the machine in which the service resides.
I've just tried out TFS 2010 today, along with Project 2010 and VS 2010. Only Later realized that without Sharepoint, TFS is only configured as Basic. This reduces it's functionality as oppose to what I've seen during VS2010 product launch. Sadly I can't find any alternative but to get a trial copy of Sharepoint to see if it serve my purpose. Well, apparently Sharepoint only comes with x64 edition. I'm not formatting any machine to x64 just to give this a try. So, after some reading up, I found that Project Server is actually based on Sharepoint. Now I wonder is whether TFS can be configure to connect to Project Server?
If it's possible, would the setting be much different that Sharepoint's?
And what am I missing from this setup as oppose to Sharepoint's?
Based on Sharepoint != Sharepoint. I think that Project Server is just a subset of Sharepoint functionality. Also, basing Project on Sharepoint allows for some really tight integration into your portal. To answer your question, I don't think you still will get your fully featured TFS without Sharepoint Proper.
FYI - Sharepoint 2007 (or 3.0 or whatever it is) is not x64 only, but will run on x86. TFS 2010 will go full feature on 2007
Sharepoint 2007 Trial
To answer what you are missing:
Reports
Project Portal
TFS Web Access
That's about it. You still get 90% of the features with your current deployment without SharePoint. Tommy is right about MOSS 2007, it comes in 32-bit and will give you all features. Project Server runs on top of SharePoint as a shared service provider. Traditionally MS releases a power toy to integrate TFS with Project Server. They said they would go over this at TechEd, which just happened about a week ago.
Also, I suspect the integration with Project Server 2010 will be better, but then you will have to run SharePoint 2010 :(
In my opinion, TFS has enough to run most projects by itself and you can use the client version of MS Project for critical path anaylsis, etc.
Use Windows Sharepoint Services for Windows 2003 & Windows 2008:
http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb400747.aspx
For Windows Server 2008 sp2 and Windows Server R2, use SharePoint Foundation 2010:
http://www.microsoft.com/downloads/details.aspx?FamilyID=49c79a8a-4612-4e7d-a0b4-3bb429b46595&displaylang=en
Both are free.
I'm not formatting any machine to x64
just to give this a try.
Why not use VMWare Server, Hyper-V, Virtual Box or some other virtualization software to run the pre-made demo/trial/lab VHD's - no formatting, no installation, no setup, more hair.
Link
I am in a situation where the corporation has just recently upgraded to TFS 2008. They have no intention of upgrading to TFS 2010 at this time. As a development group, we've moved to Visual Studio 2010 this week. As with any large corporation, we cannot get our own environment created to install TFS 2010. Steps on too many toes, and isn't corporate standard. Etc.
I want to take full advantage of the new testing features in relation to the new UI Testing and other features. This appears to require TFS 2010. So my "dream" is to do my daily work at the office and write tests, but at night, have my code synchronized with my TFS 2010 server at home and run automated builds with the full testing capabilities enabled.
So is there is best practice for this? I've read up on the Workspace theory and the binding issues that are involved and that sounds the biggest hurdle to overcome.
Possible Solution - Create two workspaces $/WorkProject and $/WorkProject-Mirror and use a custom application using FileSystemWatcher to kick off a job that synchronizes code changes and a custom rewrite of the bindings. Use job on work laptop and home machine to allow bi-directional binding.
Research to see if TFS Integration Platform will help with this
You are correct the new testing UI (Test Manager 2010) requires TFS 2010, you are also correct that you can use the TFS Integration Platform between a TFS2008 & TFS2010 server. Then use test manager on the 2010 server.
All the above should be easy, the tough part will be the bindings in the solution file. I would suggest you have a second one created that points to your TFS2010 server so that you can open the correct solution file for the correct environment without stepping on your co-workers toes.
I think the two workspace route is overkill, it's just a solution file you need.
I wonder if you could use a read-only account to perform a get from TFS2008 and then do a check-in to your TFS2010 with a more-privileged account. I'm sure those two things and a little clever PowerShell scripting could get you what you're looking for.
I would encourage you to write a second utility to monitor that this script continues to work and to notify you if it detects a failure or something.