I'm creating a C++/CLI project to wrap native C++ DLLs using Visual Studio 2017.
For wrapping generic collections I found a great library on GitHub https://github.com/goldshtn/marshalfx which looks promising, but it does not compile using VS 2017:
I get the error:
Error C2760 syntax error: unexpected token 'for each', expected 'statement'
here: link
Which is strange, as it is apparently the documented way in C++/CLI to iterate over IEnumerables.
Trying to replicate the issue, it seems it also doesn't work with very simple examples like the MSDN example below:
MDSN
So, question is, what I'm doing wrong? Do I need to include something, maybe set some compiler options, or, rewrite the indicated line in the marshal_fx library to get it working?
Related
I'm creating a script editor for my application, and I'd like to have it be able to run both C# and VB.NET scripts using Roslyn. I got this working with C# by using the CSharpScript class in the Microsoft.CodeAnalysis.CSharp.Scripting assembly/namespace, however there is no equivalent VisualBasicScript class that I can find, nor a Microsoft.CodeAnalysis.VisualBasic.Scripting assembly. I've scoured the web and can find nothing useful about running VB.NET scripts, and all the samples on the Roslyn github site are C#-specific. Am I missing something, or does support for running VB.NET scripts simply not exist the way it does for C# scripts?
Visual Basic Scripting is not currently available, presumably because it's not finished.
But its source is is the Roslyn repo, so you could try building it yourself.
When I do that, code like the following works for me:
Dim result = VisualBasicScript.RunAsync("Dim result = 1+1").Result
For Each variable In result.Variables
Console.WriteLine($"{variable.Name}: {variable.Value}")
Next
But this code does not work for me (it fails when compiling the script):
Console.WriteLine(VisualBasicScript.EvaluateAsync("1+1").Result)
I'm not sure whether this is because it's not finished, or whether it's intentional difference from C# scripting.
After building with CMAKE for visual studio 2015, I found that there were some build errors that required me to edit the code. I feel that this should not be necessary and would like to know if I might have done something wrong in build process to make these errors surface
Firstly I had to correct the compiler name from vc130 to vc140 in the files include/CGAL/auto-link/auto-link.h and cmake/module/CGAL_GeneratorSpecificSettings.cmake. I assume that this is simply because it has not been tested VS2015 and someone just assumed that vc130 would follow vc120.
The other issue I ran into was that eight functions that did not compile. These were the functions
Segment_2<R_>::min
Segment_2<R_>::max
Segment_2<R_>::vertex
Segment_2<R_>::point
Segment_2<R_>::operator[]
Segment_3<R_>::min
Segment_3<R_>::max
The issue seemed to be that the type signature of the implementation did not match that of the declaration. I tried fixing the type signature, but was unable to get it to match exactly. To fix this I ended up moving the implementation of these functions into the declaration. I would like why this is apparently necessary as presumably it compiles for other people. Sloriot commented that it was because the VS2015 compiler was more recent than the one CGAL is tested with. It is however my understanding that the visual studio compilers are backwards compatible, an thus it should not break the code to update the compiler.
The first version of CGAL officially compatible with VS2015 will be CGAL 4.7.
It seems that the new version of the Microsoft has some issues compiling valid C++ code it was accepting before. This explains why the release 4.6 of CGAL (or prior versions) has some compilation issues with that new compiler.
After I have fixed this warning, how can I make it an error, so it doesn't slip in again?
msbuild /p:TreatWarningsAsErrors doesn't work
No happy answer to give you here. The TreatWarningsAsErrors property only affects the C# and VB.NET compiler (not C++), it determines the value of their /warnaserror command line option.
But MSB3277 is generated by an MSBuild task, ResolveAssemblyReference, its internal LogResult() method generates the diagnostic. The only property the class has that helps treat warnings as errors conditionally is WarnOrErrorOnTargetArchitectureMismatch, not what you are trying to achieve. You can have a look-see for yourself with a decompiler, look at C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Build.Tasks.v12.0.dll. The resource name for the localized MSB3277 message is "ResolveAssemblyReference.FoundConflicts".
So only way to get ahead here is to write a little utility that parses the log file and looks for the warning.
You can use the generic mechanism MSBuildTreatWarningsAsErrors or <MSBuildWarningsAsErrors>MSB3277</MSBuildWarningsAsErrors> (introduced in #1928) to accomplish this.
credit: rainersigwald
Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages and all related assemblies they come with to the highest version possible.
More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
It looks like the /warnaserror will promote all msbuild warnings to errors:
TreatWarningsAsErrors vs /warnaserror
My project was perfectly building before it is refactored to support arc. Now when the refactoring is applied, it is not building and an error message is shown that language not recogonized. Any work around for this?
The linker command line shows an option "-xml2", which is wrong. You have to find and remove that option from the "Linking" options in the build settings.
I'm having troubles registering windows script file. When I'm trying to do so it says "Cannot find the type library for this reference Some.Reference"
Basically, behaviour is very similar to one described in this question Windows Scripting can't find reference but I can't figure out what to use instead of c:\path\to\control.dll.
In my case Some.Reference is Msxml2.FreeThreadedDOMDocument.4.0. so what should I actually do? I tried to use different kinds of msxml.dll, but it didn't seem to help.
Or maybe there are other ways to solve this issue?
One more detail: I managed to register this script on Windows7 but I get described error in Windows Server 2008 sp 2
Hans, thanks for your comment, because what I did is I used this tool
http://www.nirsoft.net/utils/registered_dll_view.html to view registered dlls and I found that the only abailable object I had is Msxml2.FreeThreadedDOMDocument.6.0 so I just changed my script to use this version, and as I can see from your comment it was not the worst decision