I'm attempting to migrate customizations to our new production organization from our dev organization.
I'm using solutions to move the metadata changes but for some reason it doesn't include the steps for the loaded assemblies (plugins and workflows).
Am I missing something?
I assume you have forgotten to add the message processing steps to your solution.
Add your Assemblies at "Plug-in Assemblies"
Add steps from the available Assemblies at "Sdk Message Processing Steps" -> "Add Existing" and select the steps from the list.
Related
We have an in-house Azure DevOps 2019 server and I'm currently setting up a build for a new .Net6 solution whose projects reference various packages from both nuget.org and an in-house feed in our ADO server's "Artifacts" area.
With this being .Net6, I'm assuming I have to use the ".Net Core" restore task (black square icon), rather than the older "NuGet" restore task (blue icon)? I've therefore added the former, and configured the pertinent settings as seen below, where "NuGetPackages" is the name of our in-house feed:
When I run the build, this task is failing with the message
error NU1301: Unable to load the service index for source http://***/_packaging/2df3c440-07a5-4c01-8e5c-bfbd6e132f09/nuget/v3/index.json.
The URL of our in-house feed is:
http://***/_packaging/NuGetPackages/nuget/v3/index.json, so why has the feed name in the URL been replaced with a GUID as seen in the error message? Presumably this is why the restore fails.
Incidentally we have numerous .Net Framework 4.x solutions that reference the same packages and build fine. These use the older "NuGet" (blue icon) restore task, but the settings are identical to those in the above image, suggesting that the newer ".Net Core" task is doing something strange.
(As an aside, could someone explain the difference between the "NuGet" task and the ".Net Core" task? Could I still use the older task in my .Net6 build pipeline? I tried it briefly earlier but it complained that msbuild v17 isn't installed and didn't want to continue down that path for fear of breaking the 4.x builds).
Something that hasn't been mentioned here, but has been the source of my pain when trying to restore from a feed in a different project but the same organization was certain settings of the consuming project... (sic. https://developercommunity.visualstudio.com/t/restore-nuget-task-unable-to-load-the-service-inde/1337219)
After adding the pipeline permissions to the NuGet feed (as per https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=azure-devops#pipelines-permissions), you need to update the Limit job authorization scope... settings in the project which is restoring the feed.
I just spent nearly two days fighting this same NU1301 error, and while my ADO instance is cloud-based and the "latest", i.e., not exactly analogous to your situation, maybe my experience will shed some light.
The tldr; is that there were permission issues for the ADO "project" build service account accessing the "organization" Artifact feed. The output from the DotNetCoreCLI#2 restore task didn't even hint in that direction, but when I dropped-back to using the NuGet restore task, the error messages were more informative and helped me discover the underlying issue.
This info doesn't shed light on the guid/name swap issue you ask, but maybe the guid is an internal ID that is first used to then resolve the name, and if a permissions issue prevents even querying the Artifacts endpoint ...
As for the msbuild v17 comment, I would heed very carefully this advice and your trepidation about messing with the existing builds. To paraphrase that old quip ... it's not really paranoia, if MS has a well-established history of breaking stuff that has worked just fine for a very long time! ;-}
HTH.
SC
Here are the steps that helped me fix this same issue in Visual Studio.
Make sure that you have Owner or Contributor permissions to the Feed in Azure DevOps. Something like this:
Then in Visual Studio make sure that you are signed in using the account that has the permissions from the previous step.
Finally rebuild the solution.
Hopefully this fix your issue too!
everybody.
We have just successfully migrated from ADServer 2019 to ADServices.
We have a single custom process template that is used for all Team Projects. After migration, each team project has its own Process Template, as expected.
However, as all migrated Process Templates are equal, I would like to group all Team Projects in a single Process Template.
In order to do that, I do these steps:
Go to Organization Settings
Select Process
Click on one of my hosted process templates
Click on "Projects"
Click on "..." and select "Change Process"
A pop up appears, where I can select the target process I like to change. It's important to note that all hosted migrated process seems to be avaliable for the change.
When I select another hosted process, and click "Ok", the message "The feature is disabled. Contact your Azure DevOps Server administrator." appears and the change can't be done.
I have been looking how to enable this feature with no success.
Has anyone had this situation?
If is not possible to do that, is there any way to import the future changes of my process template via command line, in order to update all my team projects ?
Thanks in advance for the help.
Regards,
Alba
We evaluated this situation with MS and the answer is that there is no way to make this change of process template between team projects belonging to different hosted process template, even though the process templates are equals.
As we cannot change our Process Template to hosted process by now, our solution was making a script using AD api, in order to make a bulk update of all process templates for all our team projects.
See https://learn.microsoft.com/en-us/rest/api/azure/devops/processadmin/processes/import%20process%20template?view=azure-devops-rest-6.1
From the screenshot, you were trying to change the process used by the team project from a hosted xml to an inherited process. For your scenario, you need to
cloned your Hosted XML process to an inherited process.
Change a project from Hosted XML to an inherited process.
An useful blog for your reference:
https://devblogs.microsoft.com/devops/moving-from-hosted-xml-process-to-inherited-process-ga/
I am building a .net solution using the Azure Devops 2019 pipeline. The solution I am building is referencing projects in another directory. These projects are located in the source control however during the build I get the following error:
> ##[error]C:\a\_work\9\s\UI\UIProject\UIProject.sln.metaproj(0,0):
> Error MSB3202: The project file
> "C:\a\_work\9\s\Te\..\..\BusinessLogic\MyBLLProject\MyBLLProject.csproj"
> was not found
If I look at the Build server drive the BusinessLogic folder is missing even though the files are located in the source control.
Shouldn´t the build server take care of referenced projects and build them as well?
If you are trying to build/restore a simple project, the restore task will not handle the referenced project.
If you are trying to build/restore solution level .sln, the restore task will handle both projects.
However, according to your error info.
"C:\a_work\9\s\Te....\BusinessLogic\MyBLLProject\MyBLLProject.csproj"
was not found
It's a project not found, not some dlls not found, the issue should not related nuget side.
Just as comment suggest, you should double check your workspace mapping relationship. Make sure the get source steps will also download the referenced projects.
If the referenced project is in a separate repo, then your build will fail. I haven't tried it myself but you can reference other repo: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops
I have two projects in TFS, WebSite and Reference, and they follow the structure:
$\
WebSite: Main project to be built
Reference: Repository with many referenceable dlls.
Website.dll uses dlls existing at Reference but, for several reasons, they are not contained in the same solution, and may be mapped to different folders that do not follow the VSTS structure.
So, in order to have the Website project compiling locally, the Reference's.dlls Hintpath at Website.csproj have been manually changed to a specific, absolute path, common to all developers' machine.
Now, we're experiencing with CI/CD, and we're thrilled with the hypothesis of having VSTS doing the dirty, tedious work of building/deploying. Thing is, since Reference.dll is not in the same project as Website, building ends up lacking essential libraries (the aforementioned Reference folder) and fails.
Is there a way of telling VSTS to GET Reference's dlls (which are compiled at this point), copy them to the directory Website.csproj is being built at and let them be used to build the main project?
What I've tried:
First:
Map Website and Reference in the Get Sources step
Using a Copy Files task, set Source FOlder as $\References and Target Folder as $(Agent.BuildDirectory)
Build
Now:
Added all the references in the main project.
In both cases, none of the references are found, and the
The type or namespace name '(namespacehere)' could not be found (are you missing a using directive or an assembly reference?)
errors are thrown.
I've been searching through the vsts help section, but can't seem to find any obvious solutions.
Any help is greatly appreciated.
It’s mainly caused by the Reference's dlls are not added in source control (TFVC repo).
First, please make sure you add the Reference's dlls into the website project. So the project file will contain the reference as below (ClassLibrary1.dll as the reference in below example):
<Reference Include="ClassLibrary1">
<HintPath>..\..\ClassLibrary1\ClassLibrary1\bin\Debug\netstandard2.0\ClassLibrary1.dll</HintPath>
</Reference>
Then you can use any of below options to make the referenced dlls work.
Option 1: add the referenced dlls into source control
If you have added .tfignore file into your TFVC repo, it will ignore files and folders under **\bin, so the reference dlls not checkin to TFVC repo by default. You can follow below options to checkin the reference dlls into TFVC repo:
Exclude the reference dlls in .tfignore
Exclude the dlls you want to refer in .tfignore. The format is:
!**\referencename.dll
Such as !**\ClassLibrary1.dll.
Add the reference dlls into source control
In VS -> Source Control Explorer -> Add items to folder -> selected the dlls.
Checkin and double check the dlls are added into TFVC repo
In VS pending changes window, there will show the dlls and the .tfignore file as Inculded changes, checkin the changes.
And double check the dlls are added into TFVC repo in VSTS web page.
Option 2: build the reference project before building website project
If you do not want to add the dlls into source control, you can also build the reference solution firstly so that the reference dlls will generate before build the website project. Details as below:
Edit build definition -> add VS Build task (specify reference solution) before building website project -> Save and queue the build.
Note: for option 2, the build configuration you specified in the relative path should be consistent with the build configuration in VSTS build definition.
Such as I specified Debug in the relative path ..\..\ClassLibrary1\ClassLibrary1\bin\Debug\netstandard2.0\ClassLibrary1.dll. So in my VSTS build definition, VS build task to build the reference project, the build configuration must be Debug.
Now, no matter which option you are using, VSTS build will not show the error message The type or namespace name '(namespacehere)' could not be found.
The correct way to approach this is to not store references in source control. Turn them into packages, store them in a package management feed, and restore them during build. Developers will automatically restore them on build.
NuGet is just great addition for Visual Studio. And it also allows for custom NuGet repositories as long as you provide custom URLs to them.
For company-related projects we can have own NuGet repositories serving whatever libraries are needed for internal projects. The main problem is that each developer has to configure this manually within Visual Studio.
Question
Is it possible to set these URLs by domain security policy settings? This would be great, because every new team member that would install Visual Studio would automatically get these URLs and gettig project source code could automatically load related libraries (with the new NuGet feature that loads missing ones on build).
So #Haacked and Steve Sanderson... Is this possible?
NuGet 2.1 introduced hierarchical configuration settings for NuGet. This allows you to specify things like additional repositories at a project/solution level rather than having to have everyone receive the settings through a group policy.
Release notes: http://docs.nuget.org/docs/release-notes/nuget-2.1
By setting a NuGet repository at the solution level, everyone working on the solution will get the additional repository added to their package sources.
That is not yet possible. I'm pretty sure there's a feature request already for this in http://nuget.codeplex.com/. I recommend finding that feature and commenting on it. If you can't find it, start a discussion. :)