I try to migrate a process from one azure devops org to another with the Azure DevOps Migration Tool.
In the answer for this question it is said if you run this command migration.exe init --options Full you get the complete configuration options that are available. But in the created configuraition file I can't find a processor for the process migration.
In your GitHub documentation there are hints that it should be possible, so I am a little confused.
Are they diffrent versions on GitHub and Chocolatey?
If I compare the version number and the release date (on the sites) then it seems they have the same version.
In the code from GitHub I found the ProcessDefinitionProcessor and tryed to find the correct configuration.
At the end i got this error:
Newtonsoft.Json.JsonSerializationException: Type specified in JSON 'MigrationTools.Processors.ProcessDefinitionProcessor, MigrationTools.Clients.AzureDevops.Rest, Version=11.11.8.0, Culture=neutral, PublicKeyToken=null' is not compatible with 'MigrationTools._EngineV1.Configuration.IProcessorConfig, MigrationTools, Version=11.11.8.0, Culture=neutral, PublicKeyToken=null'. Path 'Processors[1].$type', line 150, position 43.
With this configuration:
"Processors": [
{
"$type": "ProcessDefinitionProcessor",
"Enabled": true,
"Processes": {
"Scrum":["IWB_Scrum_VD"]
}
}
],
"Version": "11.11",
The Azure DevOps Migration tools does not migrate the Process, just the Work Items.
You can use the Microsoft project process-migrator to migrate the process.
Related
I have a plugin that fails to load initially when starting up my project and gives this error: The game module ‘PluginName’ could not be loaded. There may be an operating system error or the module may not be properly set up
When reviewing the log file I see that the issue is caused by:
Missing import: UnrealEditor-SteamVR.dll
If I copy this DLL from the Unreal Engine 5 plugins into my Plugin's Binary folder, the project will open as normal and load the plugin. However, this was not the case for Unreal Engine 4, so I'm trying to see why I need to copy this DLL now.
In my plugin Build CS file I have a reference to SteamVR. Maybe this needs to be updated?
PublicDependencyModuleNames.AddRange(
new string[]
{
"Core",
// ... add other public dependencies that you statically link with here ...
"CoreUObject", "Engine", "InputCore", "HeadMountedDisplay", "OpenVR"
}
);
PrivateDependencyModuleNames.AddRange(new string[] { "SteamVR" });
How to get this to work without manually adding in the DLL?
I edited my .uplugin file and added the SteamVR plugin dependency, which resolved the issue.
"Plugins": [
{
"Name": "SteamVR",
"Enabled": true
}
]
Edit 1:
I discovered that though multiple Steam libs were included in my C++ it was a function from the SteamVRFunctionLibrary responsible for causing the issue on startup when the SteamVR plugin isn't enabled.
I am facing some issue with setting up apache ignite-core 2.10.0 in java 11 environment.
I am getting the below exception, when I am trying to start ignite Using Ignition start method.
{"version": "0.2.0", "timestamp": "2021-08-18T08:08:51.363Z", "severity": "error", "service_id": "xxxxxxxxxxxxxxxx", "metadata" : {"category": "xxx"}, "message": "Exception during start processors, node will be stopped and close connections"}
org.apache.ignite.binary.BinaryObjectException: Failed to find empty constructor for class: org.apache.ignite.internal.processors.platform.websession.PlatformDotNetSessionLockResult
at org.apache.ignite.internal.binary.BinaryClassDescriptor.constructor(BinaryClassDescriptor.java:1088)
at org.apache.ignite.internal.binary.BinaryClassDescriptor.(BinaryClassDescriptor.java:309)
As a work around temporarily I created the default constructer in the org.apache.ignite.internal.processors.platform.websession.PlatformDotNetSessionLockResult.java class and build the jar from source code. This solved my problem and I was able to proceed. I now need a solution to this problem, so that when I integrate Ignite to build the solution I don’t have to make this change.
Also wanted to appraise you that this is being used in the containerized product which uses java11 and ignite cluster would be started in the same JVM
Thanks,
Pankaj Bhadani
Looks like a known issue, please check for the workaround in Connection from Ignite Client in Docker question.
We are using an internal NuGet feed in our Azure DevOps environment to host many different packages, which are consumed in many different projects. I would like to configure the pipeline so that whenever an internal package is referenced, it is always resolved to the latest version. All of the internal references are configured with wildcards in the PackageReference tag of the .vbproj file, like so:
<PackageReference Include="MyPackageName" Version="*" />
And the restore command in the YAML file is configured like so:
- task: NuGetCommand#2
condition: and(succeeded(), eq(variables['ModifiedProject'], 'true'))
displayName: 'NuGet restore'
inputs:
command: 'restore'
restoreSolution: '$(ModifiedProject.Directory)/$(ModifiedProject.Solution)'
feedsToUse: 'select'
vstsFeed: '[guid]/[guid]'
noCache: true
The projects build successfully, but they still end up using the oldest version of the package instead of restoring the newest version. Is there a way to force the restore task to default to the newest package version?
I ended up finding a workaround for this issue by using the Azure DevOps REST API. My objective was to get the pipeline to flow through these basic steps:
After all build steps have been completed successfully, push the new package version into the artifact feed.
Use the REST API to unlist the old package version, leaving only the newest version available.
Because of the use of floating versions in the PackageReference tags, any projects that depend on these packages will then automatically pull the newest version when they are built in their respective pipelines.
I was only comfortable going this route because "deleting" a package in Azure doesn't really delete it, it just gets moved to the Recycle Bin. In the event there is a breaking change that is discovered post-push, we can always restore a previous version to the feed. Given that this process is being used exclusively for our 50+ internal packages with their own testing processes, it definitely seems like a safe route to go, and far more efficient than any other option I can find. However, I don't think I will mark this as a definitive answer to the question, because it still feels a bit hacky and I'd prefer there was a legitimate option to force newest versions in Azure's NuGetCommand#2 task.
Code
As mentioned, I used Azure's well-documented REST API for these functions, particularly the areas governing artifacts. Although there is a page dedicated to deleting a package from a NuGet feed, I couldn't get their specification to work. I ended up inspecting the calls made from the UI and copying those, while still using my own token for authentication. This method does the history "trimming" I needed:
public void TrimPackageFeed(string feedName, string packageName)
{
var packageVersions = GetPackageVersions(feedName, packageName);
var deprecated = packageVersions.Where(x => !x.IsLatest && !x.IsDeleted)?.ToList();
if (deprecated != null && deprecated.Any())
{
foreach (var version in deprecated)
{
var url = $"{version.Links.Feed.Value.Replace("feeds.dev.azure.com", "pkgs.dev.azure.com")}/nuget/packagesBatch";
var payload = new AzurePackagePayload
{
Data = null,
Operation = 2,
Packages = new List<AzurePackagePayloadItem>
{
new AzurePackagePayloadItem
{
ID = packageName,
Version = version.Version
}
}
};
ApiRequest(url, Method.POST, null, JsonConvert.SerializeObject(payload));
}
}
}
I built this as a .NET Core 3.1 command line app, published as a self-contained executable within our build repo. I used C# because it's most familiar to me, but I'm confident this could be scripted in any language (probably even just PowerShell). I then appended the following task to the end of my YAML pipeline definition:
- task: CmdLine#2
condition: and(succeeded(), eq(variables['ModifiedProject'], 'true'))
displayName: 'Trim package feed'
inputs:
script: |
AzureApiClient -action trim-package-feed -feed FeedNameHere -package $(ModifiedProject.AssemblyName)
workingDirectory: 'Azure\AzureApiClient\Output'
failOnStderr: true
The package gets pushed to the feed, then the assembly name is passed to my API client which will trim the historical versions and leaves only the new version available to restore.
If you are using a self-hosted agent to run the pipeline, you can try to clear the local nuget cache, delete all the nuget packages in the global nuget cache under C:\Users\xxx\.nuget\packages or use clean nuget caches.
If the package to be consumed is just pushed into the feed, you need to wait for a while . There has to be a delay in populating packages on the feed.
In addition , you can try to use dotnet restore task to see if this issue still occurs . Here is a ticket with similar issue you can refer to .
I have been chasing an issue with a AspNetCore web api project running on an Azure app service for a few days.
Basically I have a very small api project that when deployed / started - I get a 500.30 ANCM error. Cryptic enough - I pulled the event log from the app service and I find this:
<Data>Could not find inprocess request handler.
Captured output from invoking hostfxr: Error:
An assembly specified in the application dependencies manifest
(SampleApp.Api.deps.json) was not found:
package: 'System.Data.SqlClient', version: '4.6.1'
path: 'runtimes/win/lib/netcoreapp2.1/System.Data.SqlClient.dll'
</Data>
Looking at the SampleApp.deps.json - sure enough I see this:
"runtimeTargets": {
"runtimes/unix/lib/netcoreapp2.1/System.Data.SqlClient.dll": {
"rid": "unix",
"assetType": "runtime",
"assemblyVersion": "4.5.0.1",
"fileVersion": "4.6.27618.1"
},
"runtimes/win/lib/netcoreapp2.1/System.Data.SqlClient.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.5.0.1",
"fileVersion": "4.6.27618.1"
}
},
I have a similar (almost identical) project that is running fine on another app service. If run the
dotnet publish -c release /property:PublishWithAspNetCoreTargetManifest=true
(the same publish command I am running with the app I am having an issue with)
I do not see this section in the runtime targets section at all in the otherapp.deps.json file.
Where is this coming from and how do I get rid of it?
I had a similar situation
a aspnetcore webapp that worked
and a dotnet cli app that failed with an almost identical error as above
What worked for me was running dotnet publish cli-proj -r win-x64. This creates a self-contained bundle, which does not rely on any installed runtime. Then my deployment was taking all the files from bin/debug/netcoreapp3.1/win-x64/publish and pushing them to my webserver.
I'm sure the installed runtime is supposed to supply these files, but it doesn't seem to work well. This "fixed" my issue.
I had a similar issue, where most projects were .Net 5.0 and one class library was .NetStandard, upgrading the .NetStandard Library to .Net 5.0 fixed the issue.
I think the issue is re;ated to not having the correct runtimes for multiple platforms, ideally run with a single platform, or install all the required runtimes.
I forgot to publish the /runtime/ folder when I published on the iis server.
Just ran into the same issue. In my case, the publish profile had target runtime set to win-x64.
Changing this to portable got the publish command to generate the runtime directory and resolve the problem.
I am trying to build a new front end application with dotnet core but getting an error as below while to open the project.
i followed that answer but not working for me.
getting this error while trying to restore :
error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
running dotnet restore command gives below error :
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.1\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I got the same problem yesterday.
Unfortunately, I don't know exactly what I was doing wrong, but I managed to solve my error.
I used the strategy on this page here
I added a global.json file in my Solution Items and I specified all the .xproj projects of my solution.
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003121"
}
Hope it helps.
Running dotnet-restore solved this issue for me. This was after i had updated the global.js to tarket the specific SDK version.
https://learn.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-restore