I'm having a hell of a time trying to get a custom policy to install on TFS2010 using VSIX.
I have the policy up and running and working fine on my development PC, I have written a value to the registry manually, and the policy is enforced.
The trouble is setting up a VSIX project and deployment to our other development machines.
I followed the instructions in:
http://blogs.msdn.com/b/jimlamb/archive/2010/03/31/how-to-implement-package-and-deploy-custom-check-in-policy-for-tfs-2010.aspx
The preferred method appears to be to use the new VSIX project type in VS 2010, I add a VSIX project to my solution, but the instructions in the blog entry are very vague about what to do next. My understanding is that the PKGDEF file means you do not have write a value to the registry when deploying, and the content of the PKGDEF file is rolled into the config when you start Visual Studio. That's fine, but how do you build up the VSIX package?
I tried adding the custom policy project to the VSIX project as a VS Package type, but when I build I get the error: The target "PkgdefProjectOutputGroup" does not exist in the project.
I have tried adding just the dll, the pkgdef file as a custom content type, etc, but nothing works.
I have changed the PKGDEF file in the blog to match my own project.
When I install the VSIX package on a development machine, I can see the add-in in the Extensions Manager in Visual Studio, but when I check the custom policies in TFS, I get the "is not registered" error.
I really need a step-by-step to setting up a VSIX project to deploy a custom policy, can anyone help?
The blog post definitely has a missing step. I think what the author intended was that you add the pkgdef file to the VSIX project (via the vsixmanifest editor) as Content of type VS Package. Then, add a project reference to the checkin policy project from your VSIX project (which will cause the checkin policy DLL to be added to your VSIX).
As a side note....when you pick "VS Package" as the content type and then point to a project...it needs to be a proper VS Package project (not just a vanilla C#/VB class library).
The problem is the assembly name "NArrange.CheckinPolicy.dll" does not match the name in the Policies.pkgdef. To correct this make sure that your Policies.pkgdef looks like this:
[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]
"TeamFoundation.Samples.CheckinPolicies"="$PackageFolder$\NArrange.CheckinPolicy.dll"
Additionally I would avoid further confusion by changing the "Product Name" in source.extension.vsixmanifest to NArrange.CheckinPolicy. This way the assembly will match the product name in VS Extensions.
Related
Im using VS 2013 (CE).
Windows Server 2012 with a local install of Azure DevOps.
I can connect to the repository via the URL
http://example.local/DefaultCollection
Under defaultCollection i have another few test projects i.e.
/DefaultCollection/A-Project,
/DefaultCollection/B-Project.
For this example i will user C-Project which im trying to add to source control.
All im trying to do is add a project to this source control but i am experiencing issues that i would have thought shouldnt exist:
In VS2013, I add a new solution. I right click the project and select "Add solution to source control". Immediately it selects the project A-Project with the path /DefaultCollection/A-Project/C-Project. I dont want this as it resides inside another project.
From the web portal i create a new project and select Team Foundation Server (not Git as the examples online i have seen all select Git). In VS i create a brand new project and then attempt the same as 1 above but it tells me that i already have a project with this name under source control. I expand A-Project and i see it listed and undo any changes but it still doesnt add as i get some form of error.
Other problems range from the local version not mapped to, existing file exists/under source control to other errors.
What is the correct process to add a project to Azure Devops when using Visual Studio 2013 CE?
The default steps are described here: Set up Team Foundation Version Control on your dev machine.
You have to:
Create a workspace from the target project.
Copy your project into the locally mapped folder.
Add your project to the source control.
As workaround:
Create workspace from the target project: Create and work with workspaces
Copy your project into the locally mapped folder.
Add your project to the source control by: Manually add files to version control
Open the project and fix source control bindings:
Useful document: Add files to the server
This question is for building Angular application in VS Code.
My team has been coding in VS2015 and using Microsoft TFS for version control (Please note that our code is within the company firewall, on a local TFS build server and not on Gits repository). For Angular, I installed VS Code and Azure Repos plugin for TFS.
Once Work-space is setup, I can see the files (I downloaded the files from VS2015 on local machine) but they all show as "Untracked" changes - why? These are checked in files.
Also, when a colleague checks-in files from their VS Code instance, my VS Code doesn't get it.
What is that I am missing here?
I figured out the issue (or a workaround). Posting my solution for any newbie facing the same issue:
Please note that my code is not in GITS or any remote repository, it is in Team Server hosted in the company data center.
I have a workspace created in VS2015 via which I mapped my Angular code and downloaded it on local machine.
VS Code Settings:
Make sure you have Azure Repos extension installed.
Go to File->Preferences->Settings (make sure User settings tab is selected)-> Extensions-> Azure Repos extension:
Provide the values for following fields:
(a) Tfvc: Location Example value for VS2015: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\tf.exe
(b) Tfvc: Proxy
Example (this should be your team server name): https://dataCenter.myCompany.com:9100/tfs
(c) Tfvc: Restrict Workspace (this is optional, use only if needed)
Check the box
Goto View->Command Palette-> type Team: Signin, provide username and password.
Goto File->Open folder-> select the folder mapped via VS2015.
Once the folder is open, you will see all files inside the folder. Go to File->Save Workspace As and give it a name.
Now you should be able to see any changes done by you in either VS2015 or VS code. Check-in should reflect the changes for you and other users connected to the code.
Previous Mistake: I realized that I was using Gits:Initialize Repository (as advised on various sites) which was causing all the trouble of "Untracked" changes and other users' changes not reflecting in my code.
Thanks,
RDV
I am following the recommendations to integrate Wix with TFS (http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html) (without having to install it on the Build server)
In my WixProj file, I have the line:
$(SourceCodeControlRoot)\wix\3.9\
This has been checked in with all of the prerequisite files - and I can successfully build on my Dev box.
But when I run my build, TFS complains that it can't find my Wix.targets file.
The error states:
*C:\Builds\8\AppName\DailyBuild\Sources\Setup\Case Tracking Setup\Wix Case Tracking.wixproj (73): The imported project "C:\wix\3.9\Wix.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
So I'm obviously using the wrong Reference but I couldn't find any other examples and the only place with SourceCodeControlRoot appears is related to Wix.
Any ideas?
Thanks
The article intends that you define or replace $(SourceCodeControlRoot) such that $(SourceCodeControlRoot) is the folder TFS exports to during the build. In your case, I'm guessing "C:\Builds\8\AppName\DailyBuild\". Of course, you probably don't want to hardcode it. You could pass a property setting to msbuild: /property:SourceCodeControlRoot="$(TF_BUILD_BUILDDIRECTORY)"
It doesn't really matter where you have your binaries (wix\3.9) folder. The end goal is to have $(WixToolPath) point to it. You could define it relative the project file if that's more convenient in your project structure:
<WixToolPath>$(MSBuildProjectDirectory)/../wix/3.9/</WixToolPath>
I refactored my MVC/Entity Framework projects by separating namespaces into separate projects. So I now have this structure:
MySolution.Data
MySolution.Data.Contracts
MySolution.Model
MySolution.Website
Everything builds and runs in my development environment. However I hit problems when I tried to deploy to my "Staging" server.
The problem I have is that it would not build when I changed the solution configuration to "Staging". In the configuration manager all the projects also have "Staging" configurations. I assume these were created when the new projects were added.
The first thing I tried was to create a new solution configuration with everything copied from Debug named "Solution 2". No luck, still fails.
Then I figured that I only need a different configuration for the Website project - where I transform the configuration file. So I changed the solution configuration, telling it to build and deploy the "Debug" configuration of Hub.Model - which from the first error message looked like the problem project. Sure enough it now builds.
The first error message (of 263) is:
The type or namespace name 'Schema' does not exist in the namespace 'System.ComponentModel.DataAnnotations' (are you missing an assembly reference?) MySolution.Model
So it looks like a problem with references to Entity Framework dlls
While I do have a workaround for now, I am concerned that this unexplained error will come back and bite me at some point in the future - probably just when I am about to deploy an urgent fix.
So why would one of my projects fail to build when I change project configuration?
You need to make sure you are installing proper nuget packages and referencing all assemblies.
The solution of the error you have shown is as below: (Reference)
You have to reference the assembly in which this namespace is defined
(it is not referenced by default in the visual studio templates). Open
your reference manager and add a reference to the
System.ComponentModel.DataAnnotations assembly (Solution explorer ->
Add reference -> Select .Net tab -> select
System.ComponentModel.DataAnnotations from the list). Then select that reference and under properties set "copy local" to true and once you publish it will be in your bin folder and wont impact at all on any server be it x32 or x64.
Happy coding :)
I'm using TFS Server 2010.
In my source I have a folder called BuildProcessTemplates. This has a child folder called Custom Assemblies.
Now, when the build runs, it happily loads the DLLs in the Custom Assemblies folder and does its thing.
I need to modify the .xaml file that defines the workflow of the build. If I double click on the .xaml file VS tries to open it but throws an error saying it can't find certain types that I know are defined in the DLL that is in the Custom Assemblies folder.
The workflow is told where to find these types when the build runs by Build Controller as it is defined as a property in the TFS Admin Console.
So, how on earth do I get VS to open my .xaml file properly? How do I let it know where to look for the DLL? I've tried moving all of the files in Custom Assemblies in to the same folder as the .xaml file, but that didn't help.
Clearly I'm missing something; I just don't have a clue what it might be.
You normally create a C# Project (Unit Test is easiest because it is pretty bare).
When you have you project you then need to:
Add the XAML as a File,
Add the Custom Activities DLL's as references.
Add the relevant TeamFoundation* references from the GAC (make sure the TFS version matches - 2010 = v10, 2012 = v11).
Also, I always open our TFS "Build Project" with VS version that matches our TFS Version, I find it keeps the number of problems down.
There's a great series of posts from Ewald Hofman here, that go through the process - I find it a bit dated, and that the Wrox Professional TFS 2012 book does a better job of explaining it, if you can get a copy.