I am getting an error while creating project in VS 2019. This is what I did
Selected "create new project"
Selected "Blank App (WinUI in UWP)" and create
It starts creating project but then throws an error
[The feed 'nuget.org[https://api.nuget.org/v3/index.json]' lists package
'runtime.win10-arm64.Microsoft.Net.Native.Compiler.2.2.1' but multiple
attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again]
Tried various ways,didn't work for me. Please help.
Related
I have an c# wpf application and an additional installer project to create an installer of the application. Among many other files, the installer project has a installer.cmd file (I took over it from someone else) and a Product.wxs file. I was able to create an installer by running msbuild tools\installer.cmd /P:Library=net461 /P:Platform=x64 command on the developper comand prompt.
I was trying to create a desktop shortcut in all user's desktops and was playing with *.wxs file for that. I know you guys will roast me because of the following sentence but I don't know what else can I say. Something I did break something and somehow the msbuild starts to give error. I cannot say what I did because I tried many different things.. I went back to original project but it didn't help. So what is done is done. I will talk about the error now.
The error itself doesn't tell much:
C:\workspace\QToolInstaller\tools\installer.cmd(117,5): error MSB3073: The command "nuget Source Add -Name PkgSrc_638107674121812897 -Source C:\workspace\QToolInstaller\exports" exited with code 1.
I checked online to understand this error code but there wasn't much. However there is another line just before this erorr line:
The source specified has already been added to the list of available package sources. Provide a unique source.
Well, this wasn't in usual warning color or marked as a warning. But I think it is worth to investigate.
So the "source" mentioned here is PkgSrc_638107674121812897. I scanned the installer.cmd to see where is this coming form and saw that this file is named by using time ticks as:
<LocalSource>PkgSrc_$([System.DateTime]::UtcNow.Ticks)</LocalSource>
Although I ran the msbuild command multiple times, the name of the source is always different. I ran the command in diagnostic mode by using -verbosity:diag option. And I checked the file name among all the logs. There is no match. I tried to change the name to something ridicolous that cannot be listed anywhere but got the same error. Removed alll the files, created them again, restarted the PC etc. Nothing have changed. This name is really unique and but still I am getting this message. I wish I had logs form previous successfull runs. I cannot tell if this is the cause of the failure or not. Does any of these ring any bell fellas?
It is solved! Luckily a colleague of mine have faced with this before. I hope no one will have to deal with this problem again.
So apparently there is a bug(?). Altought that name is unique it thinks the opposite. When I do list the sources with thw followng command
nuget source
among the one that should be there, there is one extra line as PkgSrc_638107643440982987. Although my installer.cmd suppose to remove the source every time after it is done, it didn't for once. And although the new source is named differently, it doesn't care and gives that non-warning, non-error message followed by a meaningless error code 1 message. How to solve it?
We tried to remove the source by command prompt like this:
nuget source delete -Name PkgSrc_638107643440982987
But it is not deleted. So we went to the Visual Studio->Tools->NuGet Package Manager->Package Manager Settings->Package Sources. Found the guilty source and remove it. And then it is resolved.
I am new to used the SSIS! I'm trying to use the DQS within the package to apply the business role on a specific column in the source table i.e. Contact title. This column takes different job titles related to Sales people, matching the values on the domain to the existed data. I made a package to perform this, inserting data from the source into the staging, but an error is propagated on the DQS part whenever I run the package.
[SSIS.Pipeline] Error: DQS Cleansing through Insert failed validation
and returned error code 0x80131516.
I hope someone can help / guide me!
After researching and reading many sources, I have found the solution for this kind of problems. The solution is hidden behind the reason! I simply changed the driver from default and the package was good to go. Steps to solve the issue are the following for future reference:
Step 1: Navigate to Project -> [PROJECT_NAME] Properties.
Step 2: Navigate to “Debugging” option from left panel and from Right panel, change Run64BitRuntime value to false.
I created my list and workflow that starts automatically on new entry on list.
I have another workflow that checks my list and waits for my column to come be a specific status. Then that workflow create entry in doc library.
After creation I tested it a lot and everything was great.
But in production I get errors randomly. Approximatly 50 users use that list to create items.
In the history list I get the error:
Workflow could not create the item list. Make sure the list exists and that the user has permission to add items to the list.
In the log files I found errors that say:
unable to open document ("name_of_document.docx")
and some error number:
System.Runtime.InteropServices.COMException (0x80070050)
It's not a permission problem because these error appear rarely -- most of the operations ends successfully.
Appreciate for help.
the problem could be that two process are trying to access for create the document and both create the same filename.
Try to modify the name of generated file adding more data to the name in order to differentiate the file.
Dig into the server for more information about the exception
I am attempting to follow the tutorial for CI with Azure and a Team Foundation Build Server located here, but am running into an issue with the configuration of the build configuration template XAML file, in Step 5. In trying to configure a new ConvertWorkSpaceItem, and add it to the modified build template TFS provides (TfvsTemplate.12.xaml) so that a custom script can be run on a TFS build agent, I attempt to set the property Workspace = "Workspace", but am given a compiler error: 'Workspace' is a type and cannot be used as an expression.
I've done some troubleshooting already, and the errors that have happened to others -- not scoping the CreateWorkSpaceItem, or using the wrong version of TFS or Visual Studio -- do not seem to be issues. I placed the logic correctly inside the "Run on Agent" block, so the scope should be right, and Visual Studio and my TFS Server are both running 2013. My only thought is that the instructions are out of date, and there is some other step that needs to be taken that I am missing. Any ideas?
EDIT:
Here are the parameters for the first failed convert item. The second failed Convert item is similar. The Input and Result variables are parameters defined by me for the workflow as part of the instructions for the tutorial. The error displayed is: "Compiler error(s) encountered processing expression "Workspace". 'Workspace' is a type and cannot be used as an expression."
ok this has come up a couple of times now, for TFS 2013.
Built in variables used to be available for
SourcesDirectory, Binaries Directory and Workspace
these are no longer available in TFS 2013 you now have to use
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables
to access these.
Getting the workspace is a little more complicated but if you assign some local variables you should be able to get the workspace object.
Declare local variables for sourcesDirectory (string) and buildDetail (IBuildDetail) and workSpace(Workspace) set their scope to the whole workflow
Create an GetEnvironmentVariable Activity and set its Result value to be sourcesDirectory and use Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.SourcesDirectory.
Repeat the same for buildDetail = WellKnownEnvironmentVariables.BuildDetail
Create an assign task for the workSpace object, set this one as
workSpace =
"[buildDetail.BuildServer.TeamProjectCollection.GetService().GetWorkspace(sourcesDirectory)]"
This should then give you a Workspace object to use.
note: syntax might be slightly out.
To compliment the removal of these variables MS have added a new Activity
GetLocalPath
which may be of use to you instead
I am getting the following error in a TFS 2010 build:
The work item '59' could not be updated: 'TF237086: The work item cannot be saved because at least one field contains a value that is not allowed.'
Work item 59 is a basic task I created to associate with my changeset on check-in. I have done no customization to the "task" work item. I get no errors when opening the task up and changing values manually. There is nothing in the build log that gives any clues as to what field is causing the problem.
How can I troubleshoot this issue?
Something I would do in this case:
Check the build service account, there's a high chance that when the work item is associated, its ChangedBy field is updated with this account and the value is not valid. Somebody in MSDN forum suggested checking the list of valid TFS users for a work item (you can open a bug and try typing the name in the AssignedTo field) and see if this account is in that list.
Try a checkin by yourself with the same associated task and see what fields are updated (you should be able to see this in the History tab), from there you can figure out the possible fields, and hopefully can guess the one that is in trouble.
If none of this works, I can get some more details and try to repro it on my machine. We'll need to improve error message to specify which fields that are invalid.
Hope this helps.
[Update]
The cause was indeed that the build service account (NT AUTHORITY\SYSTEM) did not have permissions to modify work items. All my attempts to fix this by editing group memberships failed, but I did get the build working without errors by using an unused project contributor's account as the build service account. Changing build service account may require the old build workspaces to be renamed or reassigned.
I had the same issue, after restarting VS 2015 IDE and entering credentials to my account on the TFS I was able to get rid of the errror.
After changing the build service account, I got a new error
The working folder xxxx is already in use by the workspace
1_1_SSSSSSSS;NT AUTHORITY\SYSTEM on computer SSSSSSSSS.
The solution to that issue is to use the TF utility to delete the workspace(s) associated with the SYSTEM build account. I had to copy the TF utility from my Laptop over to our server to run it.
See TFS Build Service Account change causes Build Failures - “Working Folder in use” Failures
Got the error on a long running build system where the user accounts had not changed.
found the WORKSPACE ID in the build log ran
tf.exe workspaces /owner:*
to confirm the workspace was on the build server and then ran
tf.exe workspace /delete 9_1_BUILDSERVER;OURDOMAIN\TFSBuild
to delete it, queued another build and no further problem.
If you changed process type, can throw this exception. Please correct your process type. My problem solved with the action.