The "CppClean" task was not given a value for the required parameter "FoldersToClean"
There is exactly one web page in The Google that discusses this error's source, as of this writing:
http://msdn.microsoft.com/en-us/library/ee862481.aspx
It sounds like the DEVENV auto-upgrader for old workspaces, solutions, and projects does not successfully handle this old C++ project of yours.
Is there any output in the Upgrade.XML files relating to it?
The CppClean task was not given a value for the required parameter FoldersToClean error occurs if the project's Output Directory or Intermediate Directory are empty or contain a macro that yields an empty or otherwise invalid result.
Specify $(Configuration) or perhaps <inherit from parent or project defaults> to solve this.
via EatMyRandom Blog.
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 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
This post asks the same question, but the answer is to use the new template that already makes use of the NugetRestore activity.
I tried to use the new template (TfvcTemplate.12.xaml) on a sample project and couldn't begin to get it to work. I suspect its a rights issue somewhere (can't access the template during the build), but I couldn't solve it. Edit: got a copy of that template and it still doesn't seem to call nuget; same problem - I need to make the NuGetRestore activity work.
In any case I have customizations already in place and only need to add in the new activity.
The problem is the activity has a "Solutions" string array property and I don't know how to pass the path to my solution. If I pass {"$(SolutionRoot)\MySolution.sln"}, I see that unexpanded literal in the log:
c:\Program Files\Microsoft Team Foundation Server 12.0\Tools\nuget.exe restore "$(SolutionRoot)\MySolution.sln" -NonInteractive
What can I pass as my solution path?
I have designed a windows form application with a .NET 4.5 target. I am trying to install the program on a couple of co worker's systems and keep receiving the same error on both systems.
System.InvalidOperationException: DataReader.GetFieldType(60) returned null.
This program basically retrieves data from a database and stores them in an excel file. It performs some calculations on the data, but nothing with the geometry type column except for retrieving it.
-I have tried installing ENU\x64\SQLSysClrTypes.msi and ENU\x86\SQLSysClrTypes.msi on the target systems.
-I have tried referencing Microsoft.SqlServer.Types and including the DLL in the files
-I have tried referencing SqlServerSpatial.DLL and SqlServerSpatial100.DLL but it does not let me add the references.
I am now having trouble finding other resources to try. Does anyone have any ideas? Thanks ahead.
I was able to finally get this working by adding a reference to
C:\Program Files (x86)\Microsoft SQL Server\110\Shared\Microsoft.SqlServer.Types.dll
and setting Copy Local to true. Odd that the nuget package worked for me in a different project, but not this one. Anyway, hope this helps somebody!
I'm trying to use the VssGet task of the MSBuild Community Tasks, and the error message "File or project not found" is beating me with a stick. I can't figure out what in particular the error message is referring to. Here's the task:
<LocalFilePath Include="C:\Documents and Settings\michaelc\My Documents\Visual Studio 2005\Projects\Astronom\Astronom.sln" />
<VssGet DatabasePath="\\ofmapoly003\Individual\michaelc\VSS\Astronom_VSS\srcsafe.ini"
Path="$/Astronom_VSS"
LocalPath="#(LocalFilePath)"
UserName="build" Password="build"
Recursive="True" />
If I write a Streamreader to read to either the database path or the local path, it succeeds fine. So the path to everything appears to be accessible. Any ideas?
Two thoughts. One, sometimes a type load exception manifests as a FNF - let's hope that's not it. But if the code is actually being honest, you can track the problem using Procmon or Filemon. Start one of those utilities and then run your task again. You should be able to track down a record of a file that couldn't be located.
#famoushamsandwich that's a great response -- I had not previously heard of procmon or filemon. Tried procmon on the problem, but even after sifting through the relevant output (my gosh the machine does a lot more stuff behind the screen than I was aware of) I couldn't find where a file I'm referencing wasn't being found.
Procmon and Filemon are good suggestions - just make sure you filter the results to only show errors. Otherwise the success messages will bury the problem entries. Also, you can filter out processes that are not at fault (either through the filter dialog or by right-clicking the entry and choosing "Exclude Process".)
A couple other thoughts:
In the LocalFilePath, you are specifying a single file as opposed to a folder. The task, on the other hand, specifies to get files recursively. Perhaps you need to remove "\Astronom.sln" from the LocalFilePath?
Is the build task being run under your account or another? It's possible you have a permissions issue
Do you already have a copy of the code pulled down in the same location? Perhaps there is a failure to overwrite an existing file/folder?