Whenever you refactor a TwinCAT project, it creates a .tmcRefac file. After building this file gets converted into a .tpr file. What are these files exactly and can I add them to my .gitignore file?
Short answer
The .tmcRefac can be ignored as also mentioned here and it was included in the official GitHub gitignore for TwinCAT. The .tpr file can't be ignored, because it contains important information about the rename history for the System Manager.
Long answer
The .tmcRefac file contains information about which variable got renamed to what:
<?xml version="1.0" encoding="utf-8"?>
<Refactors>
<Renames>
<RenamedSymbol>
<Type guid="904700f4-ab78-477a-973a-562c3c32f400">MAIN</Type>
<From>number1</From>
<To>number2</To>
</RenamedSymbol>
</Renames>
</Refactors>
After building the project with TwinCAT 4024.12 this files seems to get removed. However, if you have a stand alone plc project, it gets converted into a .tpr file. This .tpr file again contains information about the refactored variable:
<TcModuleRefactorInfos RefactorCnt="1">
<TcModuleRefactorInfo RefactorCnt="1" DateTime="2021-11-11T10:46:12">
<Renames>
<RenameSymbol>
<From>MAIN.number1</From>
<To>MAIN.number2</To>
</RenameSymbol>
</Renames>
</TcModuleRefactorInfo>
</TcModuleRefactorInfos>
Beckhoff support says about this file:
The .tpr file is required to save the rename history of I/O variables in a stand-alone PLC project, since the PLC project and the System Manager are not in the same project. I don't think you should ignore the file as it is relevant to the rename history.
Bug
If you're running TwinCAT 4024.10-4024.12 there can be a bug which crashes Visual Studio/XAE when a .tpr file is present. Solution is to upgrade to > 4024.15.
Related
I am trying to open a project which was created on one computer but has since been moved to another one due to the computer going caput. Now when I open the project and try opening the Form1.cs file, or any of the designer files, I get the error message saying "Cannot find the file 'C:...\Form1.cs'. It may have been moved or deleted". I have omitted the full path which is a reference to the old computer.
How do I change the file path so that my project can find it?
I have found another thread on this issue: Visual Studio retrieving an incorrect path to a project from somewhere
Have tried all of the suggestions (deleting .suo files, moving the project to a new folder, etc.) Nothing has worked so far. There is however in the accepted solution a reference to "Manage Workspaces" and "Source Control Explorer", which I literally can't even find in my Visual Studio window.
Help please!
Alexander
First: Open your sln file and see where it says your csproj file is located. It should read something like: "WindowsFormsApp1\WindowsFormsApp1.csproj"
Note: Everything in the parenthesis will be from the same directory as the sln file, so the true directory in this instance will be "sln_file_path\WindowsFormsApp1\WindowsFormsApp1.csproj"
As long as this is correct, then navigate to the csproj file and open it with notepad, but if this path is wrong, correct it before proceeding.
Second: Search the csproj file for the missing file, which in your case is Form1.cs
You should find something like: Compile Include="....\Erroneous_Directory\Form1.cs"
Typically all cs files will be in the same directory as the csproj file, so the line should simply read as follows: Compile Include="Form1.cs"
If the file is legitimately located in a separate directory, then provide the path, but if it is in the same directory, delete the path. Sometimes, when linking to a file in a different project, you will see this: (Link)Form1.cs(/Link), but if the file is in the same project and directory, this link line will need to be deleted.
Note: Chances are that this procedure will need to be repeated for two other files: Form1.Designer.cs and Form1.resx as well, so make sure the "Compile Include" lines for these two files are also correct before opening the solution
I've created an MSBuild proj file that contains the following header:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0" TargetFrameworkVersion="4.5" VisualStudioVersion="VersionLatest">
This proj file is used to trigger an MSBuild on a number of SSDT projects, couples with a Deploy.
For most developers, this is fine. However, one dev encounters a Deploy72002 exception when trying to run the build. According to this answer, this is due to the VisualStudioVersion not being set. Sure enough, adding
set VisualStudioVersion="12.0"
in the batch file prior to the MSBuild call fixes the problem.
However, I was under the impression (I can't find the source now) that setting VisualStudioVersion="VersionLatest" in the xml of the proj file was sufficient to make it use the highest version of VS installed. I've even tried setting it from VersionLatest to 12.0, and also moving it from the root node, into a node of it's own in <PropertyGroup>.
I'd rather not have a hardcoded reference to 12.0 in the batch file. Am I missing something obvious to make VersionLatest work?
Try this: run MsBuild with the command line option to generate a preprocessed single file. Do the same on a working computer with the same version. Diff the files produced.
It might be picking up different contents for some .props or .targets file. These have been known to change due to installing or updating some or another. I recall following a msdn article to fix such a file when I looked up a problem.
I made a huge mistaking in renaming my xml file from xcode and I'm not sure how to fix it. My app has a feature that reads all local xml files built with the project. So now it is reading 2 of the same xmls with different names.
I tried deleting the file, added it back in, and Dereferencing it but no luck. I also made sure to delete my app and re building the project. When I do a full system scan for the xml file nothing pops up. The xml file is currently in the Trash.
Another issue might have been with the svn remote server but I tried svn rm --delete filename and it said the file does not exist. ( I tried the project directory as well as a few other sub directories).
Is there a way to Dereference/delete the file from the project?
I installed the VS2010 web publishing updates yesterday, and now whenever I try to load a WiX setup project (all showing as unloaded in solution explorer) I'm getting the error:
The imported project "PROJECTNAME.wpp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.5\Web\Microsoft.Web.Publishing.targets
Where PROJECTNAME is the path to my setup wixproj file, without the .wixproj extension. I've checked through the project file and there is no reference to a wpp.targets file anywhere. I decided to try and create a blank targets file in that location and so added one with just this in it:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
But got exactly the same error - a not found exception despite the file being there!
I then dug into the Microsoft.Web.Publishing.targets file and had a look for any ".wpp.targets" text, which gave me this:
<PropertyGroup Condition="'$(EnableWebPublishProfileFile)'=='true' And
'$(WebPublishProfileFile)' != '' And Exists($(WebPublishProfileFile)) ">
<WebPublishProfileCustomizeTargetFile Condition="'$(WebPublishProfileCustomizeTargetFile)'==''">
$([System.IO.Path]::ChangeExtension($(WebPublishProfileFile), '.wpp.targets'))
</WebPublishProfileCustomizeTargetFile>
...
So that looks to be setting up a filename of PROJECTNAME.wpp.targets, but only when the EnableWebPublishProfileFile property is set to true. I added this to my wixproj file's main propertygroup:
<EnableWebPublishProfileFile>False</EnableWebPublishProfileFile>
Again though, it made no difference at all to the error. I'm running out of ideas here now!
Further update
I've been trying to repo this on a blank project (so far without success), and the messing about has narrowed the error down to this line (186) in the Microsoft.Web.Publishing.targets file:
<Import Project="$(WebPublishPipelineCustomizeTargetFile)"
Condition="'$(WebPublishPipelineCustomizeTargetFile)' != ''"/>
This is set at the top of the file:
<WebPublishPipelineCustomizeTargetFile
Condition="'$(WebPublishPipelineCustomizeTargetFile)'==''">
$(WebPublishPipelineProjectDirectory)\*.wpp.targets
</WebPublishPipelineCustomizeTargetFile>
I'm not sure how this is getting changed to PROJECTNAME.wpp.targets though?
I tried overriding this in my project file, but once again, it makes no difference at all.
Next I added an Exists() condition to the line in the targets file, now some projects are working and others are not, instead failing (on build) with the error:
The "DisableEscapeMSBuildVariable" parameter is not supported by the "ImportParametersFile" task. Verify the parameter exists on the task, and it is a settable public instance property.
My journey continues...
I experienced the same issue when trying to open a standard web project.
The proj file was referencing the following import for v10.0 targets but throwing the import error in the question which referred to v10.5 targets.
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
The same was true when I referenced a hard coded path - I still got v10.5 error
My solution was to simply back up and remove that version located at:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\10.5
I'm really not sure what other programs and projects need this version or why import paths were not followed but it go this project open for me seeming falling back to the correct version.
I am debugging a bug in my build process that happens occasionally but I can't directly reproduce it. I'm using msbuild with teamcity.
I have a dependency hierarchy like this:
Some.Interop.dll
Dependency-> SharedDllABC.dll
SomeService.exe
Depenendcy-> Some.Interop
Usually the final service exectuable gets in its release directory:
Some.Interop
SharedDllABC.Dll
ServiceExectuable.exe
However I can see in our msbuild logs that sometimes the tertiary dependency gets deleted during an Incremental Clean after everything is built resulting in:
Some.Interop
ServiceExectuable.exe
You can see it here in the msbuild log:
[src\SomeService\SomeService.csproj] _TimeStampAfterCompile
[12:32:43]: [src\SomeService\SomeService.csproj] Compile
// some other targets
[12:32:43]: [src\SomeService\SomeService.csproj] _CopyFilesMarkedCopyLocal
[12:32:43]: [_CopyFilesMarkedCopyLocal] Copy
[12:32:43]: [Copy] Copying file from "C:Projects\trunk\src\Some.Interop\bin\Release\Some.Interop.dll" to "bin\Release\Some.Interop.dll".
// some other targets
[src\Project\SomeService\SomeService.csproj] IncrementalClean
[18:54:42]: [IncrementalClean] Delete
[18:54:42]: [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeService\bin\Release\SharedDllABC.dll".
[18:54:42]: [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeServiceService\bin\Release\SharedDllABC.pdb".
[18:54:42]: [src\Project\SomeService\SomeService.csproj] CoreBuild
[18:54:42]: [src\Project\SomeService\SomeService.csproj] AfterBuild
[18:54:42]: [src\Project\SomeService\SomeService.csproj] Build
This is my direct msbuild output, I just changed the project names/dll names to match my example. By the time this Incremental Clean has occurred the SomeService.csproj has already been built. You can see that its not getting copied. However in other msbuild logs it does properly get copied and then the incremental clean doesn't delete it.
I think incrementeal clean from this post is supposed to clean dll's that were created from previous builds, but that doesn't explain how this dll didn't get built when most of the time it does. In visual studio this always works as well.
I guess I just want to know what exactly is Incremental clean, what causes it to kick in, and maybe what things I should look for when debugging a situation like this (assembly versions, timestamps, etc?)
Try the following:
Add:
<Target Name="IncrementalClean" />
to a .targets file that's included in all projects.
From --> https://github.com/Microsoft/msbuild/issues/1054
#Kebabbi recommends a good fix by editing a csproj file. As of MSBuild 15, there is a simple way to make this apply to all CSPROJ files, instead of editing each csproj file.
https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2017
Directory.Build.props and Directory.Build.targets
Prior to MSBuild version 15, if you wanted to provide a new, custom property to projects in your solution, you had to manually add a reference to that property to every project file in the solution. Or, you had to define the property in a .props file and then explicitly import the .props file in every project in the solution, among other things.
However, now you can add a new property to every project in one step by defining it in a single file called Directory.Build.props in the root folder that contains your source. When MSBuild runs, Microsoft.Common.props searches your directory structure for the Directory.Build.props file (and Microsoft.Common.targets looks for Directory.Build.targets). If it finds one, it imports the property. Directory.Build.props is a user-defined file that provides customizations to projects under a directory.
Create a file Directory.Build.props, and place it adjacent to the SLN file.
<Project>
<Target
Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE"
BeforeTargets="_SplitProjectReferencesByFileExistence"
DependsOnTargets="AssignProjectConfiguration" />
</Project>
This could be caused by a bug in MsBuild: https://github.com/Microsoft/msbuild/issues/1054.
A fix is proposed in the comments: https://github.com/Microsoft/msbuild/issues/1054#issuecomment-406438561
When MsBuild determines which items to copy from referenced projects, it should do this recursively but does not properly do this.
As a workaround the following can be added to each csproj.
<Target
Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE"
BeforeTargets="_SplitProjectReferencesByFileExistence"
DependsOnTargets="AssignProjectConfiguration"
/>
I just spent a few days trying to figure this out with a similar pattern. In our case it was nuget files that were being removed from the output folder.
NugetPackage (that drops files in x86/x64 subfolders in output folder)
LibraryA.dll
Dependency-> NugetPackage
LibraryB.dll
Dependency-> LibraryA.dll
In our case, we have a number of solution files that are built as part of an msbuild script in a certain order.
The problem was that LibraryB.csproj was included in two solution files.
Solution1 builds and output files are all present.
Solution2 builds and sees that LibraryB.dll is present and up to date, so for some reason triggers the IncrementalClean that removes the NugetPackage files from the output folder.
Once I removed the LibraryB.csproj from solution 2, the problem is solved and the files are present in the output folder.