We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
Related
I'm trying to build the minimal wxWidgets sample on Windows, using Visual Studio 2019 Commmunity Edition, following the instructions from this page for using wxwidget binaries
I opened the "minimal_vc9.vcxproj" file in Visual Studio. Visual Studio upgrades the project file.
I then added the wxwidgets.props property file to the property manager, and then tried to build ( Build | Build Solution )
It fails with the following error:
1>C:\Users\Administrator\Desktop\wxwidgets\include\wx\msw\chkconf.h(91,1):
fatal error C1189: #error: "wxUSE_UNICODE_MSLU must be defined."
I am trying to help a friend who knows C++ and uses Windows to set this up, but am not sure how to do so. Note both he and I are new to using Visual Studio as well, and I can't find any references on how to fix this by Googling.
Note I am using the project file that came with minimal (no solution file was there), and can see that in it's configuration that it says "Use Unicode Character Set" at `Project | Properties | Character Set"
EDIT: I'm attaching a picture of the IDE/files we downloaded, which I believe are the 3.1.5 version, ie release version as of Dec 4, 2021?
It looks like you're using wxWidgets 3.0, as support for MSLU was removed since v3.1.0 ~8 years ago. Please download 3.1.5 binaries and open minimal.vcxproj project file to build the sample, there is really no reason to use a 10 year old version if you're starting developing with wx.
Also, completely unrelated, but it's considered to be a bad idea to use administrator account for development. wxWidgets certainly doesn't require any special rights.
I
It is very easy to build the library yourself.
Download the source code archive and unpack it in, e.g. c:\wxWidgets
Start msvc, do ^File->Open", navigate to c:\wxWidgets\build\msw and open the file wx_vc15.sln
Select "Build->Batch Build...", click "Select All", then "Build".
When the build is finished successfully, open c:\wxWidgets\samples\minimal\minimal_vc9.sln, let msvc convert it and choose " Build->Build Solution".
Then when everything is ready, create a project as "desktop application", apply the properties file and start coding.
Thank you.
I have an application that depends on a third party library where a file starts with sign '$'.
I have read about this issue, which is discussed in this thread Visual Studio Online TFS refuses to "source control" filenames starting with $
Apparently there is no solution - but i really need a solution.
Does someone have a workarround to this or any ideas on how to solve it?
The thread is more than 2 years old so maybe something has changed that i do not know of :)
Thanks.
Still not changed. Files and folders you add to Team Foundation version control must conform to the following restrictions:
Source Link: Version control files
Files stating with $ such as $xxx.dll will auto change to xxx.dll when you checked in TFS source control.
In other words, you could not keep files stated with $ characters in TFS source control system. If you force rename a file already in source control, you will get a pop up error such as below screenshot:
I'm afraid the only workaround is renaming the third party library file.
I followed the steps to integrate Dotfuscator into my Xamarin.Android project as described here, but when it's time to build the project, I'm getting the following error:
The "_DotfuscatorXamarin_DetermineDefaultInputsTask" task failed unexpectedly.
2>\path\to\PreEmptive.Dotfuscator.Xamarin.targets(570,5): error MSB4018: System.NullReferenceException: Object reference not set to an instance of an object.
2>\path\to\PreEmptive.Dotfuscator.Xamarin.targets(570,5): error MSB4018: at InlineCode._DotfuscatorXamarin_DetermineDefaultInputsTask.Execute() in \path\to\AppData\Local\Temp\eruovv3u.0.cs:line 106
2>\path\to\PreEmptive.Dotfuscator.Xamarin.targets(570,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2>\path\to\PreEmptive.Dotfuscator.Xamarin.targets(570,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
I have looked and looked online, but no one seems to be having this issue. I think the problem has something to do with generating the default configuration file on the first build. Any ideas?
UPDATE: This issue has been fixed in newer versions of Dotfuscator. See the detailed instructions for the free Dotfuscator Community and for the commercially-licensed Dotfuscator Professional. The original answer follows below.
Full Disclosure: I am a developer of Dotfuscator at PreEmptive Solutions, and am answering this question in that role.
You're right, the problem is the default config file generation in the targets file (PreEmptive.Dotfuscator.Xamarin.targets) - sorry about that. Specifically, the build integration is attempting to discover project references, but expects the classic MSBuild project format, not the new minimal one used by .NET Standard.
You can work around this issue as follows:
In the targets file, locate the _DotfuscatorXamarinConfigTemplateLines property and copy its value (within the CDATA section) to a new file named DotfuscatorConfig.xml (or whatever value you supplied for the DotfuscatorXamarinConfigFileName property in your project file) in the same directory as your project file.
In Visual Studio, build your project once in a configuration you want to protect (e.g., AnyCPU|Release). It will error, because the new config file doesn't have any input assemblies yet, but by building now we get those assemblies in the right location for configuring Dotfuscator.
Open Dotfuscator's user interface.
For Community Edition, from Visual Studio, open the Tools menu and select PreEmptive Protection - Dotfuscator.
For Professional Edition, run Dotfuscator Professional Edition from the Start Menu.
In the user interface, File | Open the file created in step 1.
On the Inputs screen, click the "Add Input" button (a green plus-sign in Community Edition, a folder-opening icon in Professional Edition).
Browse to your project directory, then obj\Release\DotfuscatorXamarin\dfin, and then select the assemblies you want to protect.
Substitute Release with the appropriate directory for the configuration you built in step 2.
You should select assemblies that correspond to projects in your solution, and not select third-party and assemblies that are part of the framework.
Save the config file.
Navigate to the Project Properties editor.
In Community Edition, go to the Build Settings screen and select the Project Properties tab.
In Professional Edition, go to the Settings tab and select the Settings > Project Properties screen.
Add the following project properties (instructions for Community Edition, and for Professional Edition):
Property name InDir, value obj\Release\DotfuscatorXamarin\dfin
Property name OutDir, value obj\Release\DotfuscatorXamarin\dfout
Property name ReportDir, value DotfuscatorReports\Release
Substitute Release with the appropriate directory for the configuration you built in step 2. Note that the directories pointed to by OutDir and ReportDir won't exist on-disk yet.
Save the config file.
Return to the Inputs screen and select an input and click the pencil icon. Edit the path to the assembly from an absolute path to ${configdir}\${InDir}\AssemblyName.dll, substituting AssemblyName.dll for the actual name and extension of the assembly. Repeat for each input assembly.
Save the config file (and commit it to source control).
Rebuild the project in Visual Studio. The build integration will use your config file instead of trying to generate a new one.
on top of the Joe's marvelous solution I ended up changing one value from true to false with regards to the instructions on https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_xamarin.html#pctoc-setup
to get my android solution to build/run.
<DotfuscatorXamarinGenerateNewConfigFile>false</DotfuscatorXamarinGenerateNewConfigFile>
I've been configuring the Dotfuscator Community Edition at Xamarin.Android project according to this user guide. And I also had the following build error (pretty the same as #AxiomaticNexus):
Error The "_DotfuscatorXamarin_DetermineDefaultInputsTask" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at InlineCode._DotfuscatorXamarin_DetermineDefaultInputsTask.Execute() in c:\Users\user\AppData\Local\Temp\wqhfhbsk.0.cs:line 106
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() eKey.Droid C:\VSProjects\dotFuscatorTest\PreEmptive.Dotfuscator.Xamarin.targets 570
I've fixed this issue using #Joe Sewell's Full Disclosure.
I hope PreEmptive Solutions will realese the fixed version asap!!!
At some point I was missing the file PreEmptive.Dotfuscator.Xamarin.targets in the root of project. I already executed the instructions above described by Joe Sewell, but later noticed the missing file.
Error were like this:
Error The "_DotfuscatorXamarin_DetermineDefaultInputsTask" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at InlineCode._DotfuscatorXamarin_DetermineD efaultInputsTask.Execute() in c:\Users\hieta\AppData\Local\Temp\k3a5f2bj.0.cs:line 106
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() WorkSafe.Droid
Just FYI if anyone else could avoid waste of time.
When I compile a project in XE8 (with update 1), I get frequently a error that a file is missing, although the file is just available. And when I compile again, it is another file that is missing. It seems random. After a few compiles (sometimes more or less) I have build the project. And even at Run (F9) I sometimes get the error that a file is missing.
Like #Andrei Galatyn said at the end of his post, it will be solved when you delete your Android configuration in SDK versions. But I want to be able to develop with Android. What is the real problem?
I couldn't find a solution on the internet yet.
Is there a solution for this problem? Thanks in advance!
I have similar problem with Delphi XE8/XE7 at least at 3 different PCs (home PC, notebook, VMW-based virtual machine in office). All PCs are fast, all are SSD-based. Usually i get the error message when trying to build large project, for small projects errors are very rare (but happens time to time anyway). So i am quite sure that it is problem with Delphi. What i tried:
added src/dcu paths as exception to antivirus
disabled indexing of files in Windows (Windows 7 x64/Windows 8.1 x64)
deleted all SDKs for mobile development in IDE (this step was most usefull in my case).
It doesn't solve the problem for 100%, but now i see that random message only few times per week. I will be glad to see real solution.
Just for information - many errors like "file YYY\XXX.pas not found" where with wrong path to the file, it was path somewhere inside of Android SDK. After deleting of all SDKs (fortunately i need only with Win x32/x64 platforms) i never see such errors anymore.
Some time ago i sent it to my colleagues:
Many times i got an sporadic error in Delphi IDE like this:
F2039 Could not create output file '.\dcu\FireDAC.Comp.DataSet.dcu'
When I just tried to compile again, the problem disappeared but compilation may fail on another file. It was especially annoying when I need to rebuild an large project, for example <...>. Finally I discovered that under some conditions Delphi is trying to access files at wrong path:
C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk\tools\dcu\FireDAC.Comp.DataSet.dcu
Instead of
C:\M2014\Fellesressurser\felles\FireDAC.Comp.DataSet.dcu
All the time when I get the error it was try to access Android SDK folder instead of my application folder.
If you experienced same problem, you can solve it now, just delete Android SDK from Delphi IDE:
Open “Tools\Options\Environment Options\SDK Manager”
Select installed SDK (list “SDK versions”)
Delete it (button “Delete”)
I've just written the first version of a workflow activity that will run Resharper's Code Issues on the projects and parse the output to display the issues as build warnings and errors.
At first, I was going to just call Resharper's command line and parse the resulting xml manually. After fiddling with the dlls in Resharper's SDK (through disassembly mostly), I found a way to parse the results using it's own public classes, which I figured was a much more elegant and safe way to do this.
The first problem I have is that that nuget package is absolutely huge. There is 140mb of files in there, which to me is absurd for a single, unpartitioned package. There seems to be such heavy coupling between them that by using just a few model classes and the parser class, I have to drag a dozen or so of those dlls along, some of them which seemingly have nothing to do with the main dlls I need. This is not a show stopper though, I'm struggling with something else now:
In the end, I managed to track down the dependencies I needed to 41 assemblies (which is, again, insane, but alas). Initially, I tried removing everything and adding the missing references one by one, but this turned out to be unreliable, still missing some indirect references, even after compiling successfully. Then, I decided to code a small console application to find all referenced assemblies in the main Resharper assemblies I used, which gave me the 41 references I mentioned. This is the code I used to find every dependency.
Since these are custom activities we are talking about, I decided to create a unit test project to validate them. Using these 41 references only, everything works correctly.
When I added the activity to the build workflow though, and pointed the build controller to the source control folder containing the required assemblies, every time I schedule a build, the process fails stating that I need one extra dll from Resharper's SDK. For example, this is the first one it asks:
Could not load file or assembly 'AsyncBridge.Net35, PublicKeyToken=b3b1c0202c0d6a87' or one of its dependencies. The system cannot find the file specified. (type FileNotFoundException)
When I add this specific assembly to the TFS folder, I get another similar error for another dll, and this keeps going on and on.
What I wanted to know is how can I know exactly which assemblies a workflow XAML will need in order to run correctly? My custom activity dll has two specific CodeActivities and a XAML only activity that uses these two. This XAML acticity is what I'm directly using in the modified workflow template.
I see that besides the references in my project, the XAML activity also contains a TextExpression.ReferencesForImplementation section, with some assembly names. I've run my dependency finder program on those dependencies too, and the results are the same 41 assemblies already at the TFS folder.
Meanwhile I'll go with having the whole SDK into the custom assemblies folder, but I would really like to avoid this in the future since it has such an enormous amount of unneeded and big dlls in there.
First, we have request for our command line tool to support workflow activity and we decided to implement just plain MsBuild task which is universal and works in TFS too. Task and targets files are included in ReSharper CLT 8.2.
Second, if you still want to implement workflow activity it's pretty easy to do with new API in CLT, designed specially for custom processing of found issues - http://confluence.jetbrains.com/display/NETCOM/Custom+InspectCode+Issue+Logger.
And last, but not least, you do not need to put in VCS binaries of ReSharper SDK package.
Use NuGet's restore package functionality.
If you have any other questions I'll be glad to answer them.
A custom activity is being load and run by .NET CLR like any other .NET program. If the stack trace reports a missing file, then it's required by the CLR and you can't change this fact without refactoring your code.
Having an entire SDK references in the custom assembly folder doesn't make sense. I would prefer GAC deployment over huge binaries folder in the source control. Or maybe consider having these activities running an pre\post build scripts in MSBuild or PowerShell.