I use TFS2010 for source control and a build agent on windows server 2008 R2 (x64) for continuous integration.
Recently, we introduced a lightweight client application X that uses Office 2007 Primary Interop Assemblies to interact with Excel. The app has many dependencies to various projects in the solution. No other project have any dependency to X.
This is all well and good except that X wont build on the build server. From reading a few blog posts and some posts here on StackOverflow, I understand that it is not advisable to attempt to install these PIA's on my x64 build server. And that doing so will involve a bit of hacking in registry.
The solution has more than 30 projects and I do not want to duplicate the .sln in order to create a bastard BuildServerVersion.sln (or something) that contains the 29 projects that I DO want to build on the build server.
Is there a simple way to either satisfy the dependencies to the Office 2007 PIAs or to make the build agent stop trying to build that particular project? I suppose we could build and deploy just app X from a developer machine. It is an internal tool, anyway.
Related
We are attempting to upgrade our rather old TFS environment from TFS2008 to TFS2015. The upgrade of the server and database is not a problem and is fine.
The issue is our build machine. This is still a Windows 2003 Server that is running Visual Studio 2010 and VB6. We still have a need to use this build machine to build legacy VB6 projects. We have installed the TFS2010 XAML build controller on this server and successfully connected it to our test TFS2015 server. However when we try to run a Xaml build, (any Xaml build regardless of whether it builds VB6 or .NET) we get the following error message almost straight away.
TF900560: Could not start build: Cannot set unknown member 'Microsoft.TeamFoundation.Build.Workflow.Activities.TfsBuild.TargetsNotLogged'.
The XAML build are using the 'UpgradeTemplate.xaml' template and using the TFSBuild.proj we used under Visual Studio 2010.
We have a also set up a TFS2015 build controller on another (Server 2012) machine and that successfully starts the build process. However, our VB6 projects use a lot of third party components that will not install on Server 2012 so we can't use that.
Has anyone ever set up this kind of arrangement before? Is there anything we are missing or are doomed in this scenario? Obviously, we'd like to move away from VB6 apps, but that is not possible in the medium term.
I am having a Windows application which was created on VB.Net and Visual Studio 2008, The application is somewhat big and is around 10 years old. The repository we are using is TFS. I am having a task to create an automatic build for this Windows application and I choose the Jenkins CI for it.
My plan is to build the project solution using MS Build plugin and then publish it and deploy the solution to IIS path.
I have given the below MS Build query to build using Jenkins and get the solution code from TFS and the output was successful:
/t:AppProcSolution /p:Configuration=Release /maxcpucount
But I need publish the same AppProcSolution. Could I do it by passing any other parameters to the above script or should I need to use MS deploy etc. I am totally new to automatic integration. Is it possible for me get the published solution to a particular folder? Almost all the .Net integration using Jenkins tutorial available on the Internet is for deployment to GitHub etc. So if someone has any guidelines to help please provide me a solution.
MSDeploy is good for server application deployments like web applications/sites, SQL server databases or Windows Services.
When you say "Windows application" I assume you mean a WinForm or desktop client application. The best tool for this, in my opinion, is ClickOnce:
https://msdn.microsoft.com/en-us/library/142dbbz4(v=vs.90).aspx
You could also use a Setup project in VS:
https://msdn.microsoft.com/en-us/library/ms235317(v=vs.90).aspx
Can't seem to find an answer to this on MSDN or on here, does the Team Foundation Server 2013 API expose any methods to allow Project Creation? and if so in which classes?
No: project creation is a complex process involving many modules (DLLs). In fact, it requires Visual Studio (or Team Explorer) the same or newer version of TFS.
If you need to automate, you may use the tfpt createteamproject command line tool.
Update 2016-07-22: Since TFS 2015 Update 2 it is possible to create a project using the REST API.
Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.
I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.
I am on windows 7 enterprise
I have infopath 2010 installed my pc and have used it before
But due to my requirements I have to use object model to write code and it requires I add a reference to SharePoint
I read some article but it does not have any solutions for my need (it was on web part and remote debugging, they talked about export the registry and import it to local box)
My question is what do I need to install (bare mininum of SP Foundation or whatever it is) on my local pc so I can develop code and add sharepoint reference in visual studio.
Well the bare minimum is to add the Microsoft.SharePoint.dll (located in the 14 hives folder) to your project - but you are not going to be happy with it. You might be able to write code and the compiler will not complain about missing references but you will not be able to debug or get any information from the SharePoint objects because all information is stored in the specific databases (config db, content db).
The best solution is to install SP Foundation (preferably in a VM) - if you want to code against features which are only available in the Standard/Enterprise version (for example InfoPath Froms Service) you will have to install the correspondig version.