How do I add a contributor to a TFS2010 project via PowerShell?
Watching the powershell documentation (C:\Program Files (x86)\Microsoft Team Foundation Server 2010 Power Tools\Help\PowerShellCmdlets.mht), it looks like there is no option to add users to groups in TFS. But if you have the TFS Power Tools installed, you can use the tfssecurity tool in the command line.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>tfssecurity /?
[...]
/g+ groupIdentity memberIdentity (/collection:CollectionURI | /server:ServerURI)
Adds a user or a group to an existing group.
[...]
Identity Specifiers:
sid:sid - References the identity with the specified SID.
Example: sid:S-1-5-21-2127521184-1604012920-1887927527-588340
n:[domain\]name - References the identity with the specified name. For Windows, name is the logon name. If the referenced identity is in a domain, the domain name is required. For application groups, name is the group display name and domain is the URI or GUID of the containing project. In this context, if domain is omitted, the scope is assumed to be collection-level.
Example: To reference the identity of the user "John Peoples" in the domain "Datum1" at the fictitious company "A. Datum Corporation, you would use the following syntax:
n:DATUM1\jpeoples
Example: To reference application groups, you could use either of the following syntaxes:
n:"Full-time Employees"
n:00a10d23-7d45-4439-981b-d3b3e0b0b1ee\Vendors
[...]
So it would look like:
tfssecurity /g+ [ProjectName]\Contributor Domain\UserName /collection:http://yourTfs:8080/ProjectCollection
Related
When I load Package Manager Console within Visual Studio 2017 v15.9.6 in a project that uses Entity Framework I receive the following error:
\packages\EntityFramework.6.2.0\tools\init.ps1 cannot be loaded because its operation is blocked by software restriction
policies, such as those created by using Group Policy.
At line:1 char:45
+ ... rgs+=$_}; & 'C:\Bitbucket\project-path\packages\EntityFramework.6.2. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
This prevents me from running commands specific to Entity Framework like "Update-Database" or "Add-Migration".
Here are things I have tried:
Reinstall Visual Studio
In Group Policy Editor, for both Computer Configuration and User Configuration, I have enabled the setting "Turn on Script Execution" that is located at "Administrative Templates\Windows Components\Windows PowerShell". The setting for both configurations has the "Execution Policy" set to "Allow all scripts".
I've tried locally in the Package Manager Console setting the "Process" scope to both "Bypass" and "Unrestricted", and then manually loading the Entity Framework init.ps1 script. I receive the same error.
I've also tried modifying registry keys for PowerShell to set the ExecutionPolicy to "Unrestricted" in a few places. Those places are at:
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.SqlServer.Management.PowerShell.sqlps120
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.SqlServer.Management.PowerShell.sqlps140
I've restarted multiple times in between doing all of the above.
When I run the command "Get-ExecutionPolicy -List", here are my results"
Scope ExecutionPolicy
----- -----------------------
MachinePolicy Undefined
UserPolicy Unrestricted
Process Undefined
CurrentUser Unrestricted
LocalMachine Unrestricted
After all of the above I expected to be able to just load Visual Studio as normal, launch Package Manager Console, and not receive any errors when it tries to run the Entity Framework init.ps1 script. I must be missing something or doing something incorrectly. What do I need to do to get Visual Studio to work as expected?
Some more information is that this is a computer joined to a company domain, but no other developers have this issue. There isn't a group policy set by an administrator that is trickling down preventing me from running scripts.
The error may be occurring because of an invalid certificate from Microsoft. Check in Control Panel => Internet Options => Content => Certificates on the Untrusted Publishers tab. Remove Microsoft Corporation from this list.
Sounds bizarre but it worked for me.
Tks https://github.com/NuGet/Home/issues/7158
Remove file inside
control=>internet option => content => certificates =>Untrusted publishers
then problem will solve
Try downgrading to EF 6.1.2.
I ran into the same problem as you. I tried changing the Group Execution Policies which in my case didn't work, because of some restriction on my local machine (may be set by my school admin). In another project I used 6.1.2 where things like migration was no problem.
In previous versions of TFS (before 2015), there was a build environment variable for PowerShell called: TF_BUILD_DROPLOCATION, which gave the The location of the drop:
https://msdn.microsoft.com/library/hh850448%28v=vs.120%29.aspx.
I can't find the equivalent variable in TFS 2017.
What is the best practice to get it?
With Build agent tasks taking over things are different. What I do to see the various build environment variables is to make a simple batch file containing this:
SET C:\temp\EnvVars.txt
That'll produce a quick list of what is available.
Here's what I see with the TFS 2017 build agent:
agent.jobstatus=Succeeded
AGENT_BUILDDIRECTORY=C:\Agent\_work\2
AGENT_HOMEDIRECTORY=C:\Agent
AGENT_ID=2 AGENT_JOBNAME=Build
AGENT_JOBSTATUS=Succeeded
AGENT_MACHINENAME=BUILDMACHINE
AGENT_NAME=BUILDMACHINE
AGENT_OS=Windows_NT
AGENT_ROOTDIRECTORY=C:\Agent\_work
AGENT_SERVEROMDIRECTORY=C:\Agent\externals\vstsom
AGENT_TEMPDIRECTORY=C:\Agent\_work\_temp
AGENT_TOOLSDIRECTORY=C:\Agent\_work\_tool
AGENT_VERSION=2.122.1
AGENT_WORKFOLDER=C:\Agent\_work
BUILD_ARTIFACTSTAGINGDIRECTORY=C:\Agent\_work\2\a
BUILD_BINARIESDIRECTORY=C:\Agent\_work\2\b
BUILD_BUILDID=2036
BUILD_BUILDNUMBER=Database Build_20190708.2
BUILD_BUILDURI=vstfs:///Build/Build/2036
BUILD_CONTAINERID=2281
BUILD_DEFINITIONNAME=Database Build
BUILD_DEFINITIONVERSION=17
BUILD_QUEUEDBY=Smith, John
BUILD_QUEUEDBYID=8c588342-b87a-40cb-9b8c-a0ed10b57a3f
BUILD_REASON=Manual
BUILD_REPOSITORY_CLEAN=false
BUILD_REPOSITORY_GIT_SUBMODULECHECKOUT=False
BUILD_REPOSITORY_ID=$/
BUILD_REPOSITORY_LOCALPATH=C:\Agent\_work\2\s
BUILD_REPOSITORY_NAME=Collection
BUILD_REPOSITORY_PROVIDER=TfsVersionControl
BUILD_REPOSITORY_TFVC_WORKSPACE=ws_2_2
BUILD_REPOSITORY_URI=http://TFSSERVER:8080/tfs/Project/
BUILD_REQUESTEDFOR=Smith, John
BUILD_REQUESTEDFOREMAIL=John.Smith#Mailinator.com
BUILD_REQUESTEDFORID=7a588222-b66a-40ee-9b2a-a0ba10b12a3f
BUILD_SOURCEBRANCH=$/Collection/Project/Code
BUILD_SOURCEBRANCHNAME=Code
BUILD_SOURCESDIRECTORY=C:\Agent\_work\2\s
BUILD_SOURCEVERSION=9811
BUILD_SOURCEVERSIONAUTHOR=Smith, John
BUILD_SOURCEVERSIONMESSAGE=Added missing permission
BUILD_STAGINGDIRECTORY=C:\Agent\_work\2\a
You can list all Environment Variables with the following command:
get-childitem ENV:\
I am assuming you could create a simple build job that executes this and then look at the console output to determine what the name is of the Environment Variable you need.
I am using Visual Studio Online - Package Manager Preview, along with the new build system. The package manager preview adds a number of build steps, including a "NuGet Publisher" step, which should push packages to the private feed hosted by Visual Studio Online.
Now the documentation is a little out of step here. As is the documentation on auth and personal access tokens. There are some indications that you shouldn't need auth between VSO and the Package Manager as long as you have permissions set up (the build service account has permissions to the service endpoint and to the package manager extension). The actual build step asks you to select from your list of Service Endpoints, so that is what I have attempted.
When I place no credentials on the Service Endpoint, I get the error:
Server Key must be set, set the password on the generic service
When I attempt to place the API key against the Service Endpoint it seems to be discarded on save... and the error changes to:
2015-11-18T08:35:24.5678951Z Invoking nuget with push C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg -s https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/example/nuget/v3/index.json usfusmx4ez6mlfqwpp2abzc7e37denfcp7bxsep2hqij3tp4qwvq on C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg
2015-11-18T08:35:24.5688946Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe push C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg -s https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json usfusmx4ez6mlfqwpp2abzc7e37denfcp7bxsep2hqij3tp4qwvq
2015-11-18T08:35:25.3467312Z Please provide credentials for: https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json
2015-11-18T08:35:25.3667189Z ##[error]Object reference not set to an instance of an object.
2015-11-18T08:35:25.3677179Z UserName: Password:
2015-11-18T08:35:25.4647059Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
I have also attempted to use a personal access token to no avail.
How do I get the publish step working?
The in-box NuGet Publish task has two options: "external" feeds and "internal" feeds. External feeds are intended for 3rd party services like NuGet.org, Artifactory, and expect a service connection with an API key.
Internal feeds are those hosted by Team Services. Instead of a service connection, you add the URL of the feed's NuGet endpoint. The build system relies on the Project Collection Build Service (for collection-scoped build definitions) or Project Build Service (for "this project"-scoped build defs) being a Reader or Contributor to the feed. Docs for all that are available here.
UPDATE: It is all fixed now so you can use the standard packaging steps in vNext and they work like a charm.
For the time being, I am substituting the NuGet Publisher step with a PowerShell build step.
This slots into the build after the "NuGet Packager" step and allows me to specify all of the credentials by setting up a package source before pusing the package.
$feedUrl = "https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json"
$packagePath = $ENV:BUILD_REPOSITORY_LOCALPATH + "\YourOrg.YourComponent." + $ENV:BUILD_BUILDNUMBER + ".nupkg"
Write-Host "Adding package Source"
$addSourceCommand = $ENV:BUILD_REPOSITORY_LOCALPATH + "\nuget sources add -name ""Example"" -source " + $feedUrl + " -username ""your.username"" -password ""yourpassword"""
Invoke-Expression -Command $addSourceCommand
Write-Host "Pushing package to NuGet"
$pushCommand = $ENV:BUILD_REPOSITORY_LOCALPATH + "\nuget push $packagePath -Source " + $feedUrl + " -ApiKey Example"
Invoke-Expression -Command $pushCommand
I landed here because I'm researching/configuring an internal deploy -- where I'm running my own NuGet Server (nuget.server, as opposed to visual studio online). The error was the same (or has similar text):
Object reference not set to an instance of an object
My solution, it turned out, was that the URL wasn't right.
The correct version is: http://server-name/NuGet/api/v2/package
For completeness, I had: http://server-name/NuGet/ which was wrong.
I'm trying to setup a deploy process that targets 16 web sites each hosting an instance of the same application.
Websites and AppPools are named as such:
appServer1:
app10.site.com
app11.site.com
app12.site.com
app13.site.com
appServer2:
app20.site.com
app21.site.com
app22.site.com
app23.site.com
etc.
etc.
...with each website having a correspondingly named AppPool.
I am desperately trying to determine how to use a single Deploy NuGet Package step to target all of these websites/app pools using variables and a combination of powershell scripts if possible.
I'd like to have a single step where I can variable substitute the website and app pool names. As this is the only difference. I basically need the equivalent of being able to loop the nuget package step passing it a list of website and app pool names. I cannot simply use variables because I can only resolve to the machine level with variable scoping.
Create list of all Website and AppPool names, iterate them passing each value to a Step for execution. ForEach processing step for lack of better words.
I do have the ability to rename the AppPools if need be for a more consistent pattern, but I cannot change the website names
Any ideas would be greatly appreciated.
http://help.octopusdeploy.com/discussions/questions/3481-every-website-in-the-deploy-has-a-different-apppool-and-website-name-how-to-deal-no-other-differences
There's a lot to your question, but I'm going to take a stab at explaining our approach, in hopes of jogging your creative juices.
tl;dr
simply put, use your own powershell scripts to install the web-application. In there you can set the app pool name on a per website basis
For starters, we do do a separate deployment step for each project. The scripts we use will allow you to do all deployments from a single deploy.ps1 (including unique appPool names), but we find that it really helps keep each deployment nice and lean, and easy to manage. Each project get's it's own nupkg and therein contains the predeploy.ps1, deploy.ps1, and postdeploy.ps1 as well as a folder of build/deploy scripts that we've open sourcesd, and a folder of environment config xml files.
A sample of an environment config would be this. The name is simply [envName].xml
<!-- environments\Production.xml -->
<environmentSettings>
<webSites>
<app>
<physicalPathRoot>c:\inetpub</physicalPathRoot>
<physicalFolderPrefix>appname</physicalFolderPrefix>
<siteProtcol>https</siteProtcol>
<siteName>appname.tld</siteName>
<siteHost>appname.tld</siteHost>
<portNumber>443</portNumber>
<appPath>/</appPath>
<appPool>
<name>appname.tld</name>
<!-- valid identityTypes are: [LocalSystem, LocalService, NetworkService, SpecificUser, ApplicationPoolIdentity] -->
<identityType>NetworkService</identityType>
<!-- Set this value to the User the Service will run under in the format DOMAIN\username -->
<!-- If Running as 'NetworkService' then 'NT AUTHORITY\Network Service' is used -->
<userName>NT AUTHORITY\Network Service</userName>
<!-- Leave blank unless using SpecificUser -->
<password></password>
<maxWorkerProcesses>5</maxWorkerProcesses>
</appPool>
</app>
</webSites>
<serverDatabase>
<name>database_name</name>
<connectionString>REPLACED BY OCTOPUS</connectionString>
<providerName>System.Data.SqlClient</providerName>
</serverDatabase>
</environmentSettings>
You can see in the corresponding Get-EnvironmentSettings.ps1 where we load up the config, and then update it with any Octopus variables. This is the trickiest part, because we use dot-Notation to update the paths (case sensitive).
Our octopus variables really only contain information that is secret, as everything else lives in [environment].xml
| Name | Value | Scope
--------------------------------------------------------------------------
| webSites.app.appPool.password | supersecret | Production
So now a typical deployment script simply imports the modules, grab environmentSettings, update config, and install the web app.
# Top of the script, get Octopus environment and version
param(
[string] $version = $OctopusPackageVersion,
[string] $environment = $OctopusEnvironmentName
)
# Make sure a failed deployment actually fails
$ErrorActionPreference = "Stop"
# Import the modules
$currentDir = Split-Path $script:MyInvocation.MyCommand.Path
$moduleDir = "$currentDir\modules"
Import-Module BuildDeployModules
# Grab the environment settings
$environmentSettings = Get-EnvironmentSettings $environment "//environmentSettings"
$databaseSettings = $environmentSettings.serverDatabase
$websiteSettings = $environmentSettings.webSites.app
# update the config
Update-XmlConfigValues $currentDir\website\Web.config "//appSettings/add[#key='databaseName']" $($databaseSettings.name) "value"
Update-XmlConfigValues $currentDir\website\Web.config "//connectionStrings/add[#name='databaseConnection']" $($databaseSettings.connectionString) "connectionString"
Update-XmlConfigValues $currentDir\website\Web.config "//connectionStrings/add[#name='databaseConnection']" $($databaseSettings.providerName) "providerName"
# Install the web application
Install-WebApplication $environment $websiteSettings $version "anonymousAuthentication"
In doing all of this, the web application is installed into IIS with a specific application pool, and appropriate config transforms without relying on any unknowns.
Our nupkg structure looks something like this
appname.1.2.3.4.nupkg
environments
dev.xml
staging.xml
qual.xml
production.xml
modules
[all of our build modules]
website
[all of our website files]
This is super repeatable, easy to maintain, and easy to edit config. Hope it helps
I developped a VSTO SE Excel 2003 add in.
When launching and debuging the add in from visual studio, it works well.
But when I try to deploy it from my own install it never works.
To sum up, here is my install process:
the files are copied at the right location
I register the addin:
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\
with the appropriate values (Default, CommandLineSage, Description, FriendlyName, LoadBehavior, Manifest).
I also add entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ (with CLSID key including an UUID)
And HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
with InprocServer32 (with the manifest name and path, the addinloader.dll fullpath), ProgID (with the assembly name (without extension)), Programmable and VersionIndependententProgID (with the assembly name too).
I set the fulltrust policy to the url of every assemblies using caspol -m -ag "xxx" -url "MyUrl\Assemblies.dll" FullTrust -name "name"
Do I miss something ?
In the deployment machine, check whether the following are available:
Currect version of VSTO Runtime
Office 2003 Primary Interop Assesmblies
regards,
yenkay...
A good way to debug VSTO installation/loading issues is to have VSTO show you all errors. To do that, create an environment variable called VSTO_SUPPRESSDISPLAYALERTS with the value 0, reinstall/repair your addin, then try running Excel again.
It looks like the problem is with your registry keys. Check out the following link:
http://msdn.microsoft.com/en-us/library/bb386106.aspx
Your Software\Classes and Software\Microsoft entries should be under the same key, either HKCU or HKLM. If you have one under HKCU and the other under HKLM, it messes up the addin.
So I think the registry entry HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ should be HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Excel\Addins.
HTH...