I have finally come across something that no one else seemed to have come across (at least from what I can tell). I trying to build an F# type provider using TypeProviders.SDK.
As soon as I build the solution I get the error: "FS0810, Property 'CultureName' cannot be set, \LemonadeProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs" on line 2090 and again at 3162 in the design time project of the solution.
I do not think this is useful but the Test project also fails as it can not find the LemonadeProvider.Runtime.dll. I am assuming this will get created when the Runtime project will build successfully.
PS: As of right now I am just tring to build the provided template, I have not changed the code or added anything to it. Hence I have not attached any code, but please feel free to ask for it.
The corresponding issue is https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/353
Known workarounds
Change minimum target to net461. Replace all instances of net45 with net461, except for in netfx.props, where you can just delete the lines referencing net45* frameworks (I suspect the removal of those lines isn't strictly speaking necessary).
I did this workaround but am now facing these kinds of errors: (like 2000 of them)
C:\Users\user\source\repos\HelloWorldProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs(34,7): error FS0074: The type referenced through 'System.Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'. [C:\Users\user\source\repos\HelloWorldProvider\src\HelloWorldProvider.DesignTime\HelloWorldProvider.DesignTime.fsproj]
I found out that the issue lied with the ProvidedTypes.fs and ProvidedTypes.fsi files created by the SDK.
The issue was solved for me when I replaced the files with the ones found in 'SDK-dsyme-patch-7' which provided compatibility for different .Net environments which was missing from the original SDK. There might be other differences but this is the one I found and it fixed the problem for me.
The files can be found under '/src/' in the dsyme patch.
The code I am referring to is as follows and has been added twice to the ProvidedTypes.fs:
#if NETSTANDARD
asmName.CultureName <- System.Globalization.CultureInfo.InvariantCulture.Name
#else
asmName.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
#endif
asmName
I am not aware if there is a new SDK that has solved the problem. But at the time when the question was asked, this is what worked for me.
Related
I have a Xcode project I got from another developer. Initially when I opened it it has a bunch of errors (most of which were un-updated frameworks). I got it to work after a while and I fixed it. I want pass it back to the manager since I'm leaving uni in a few months. I copied it over to my friends Mac to see what would happen if I just took the project and all it's folders and made it a zipfile. It didn't work for some reason. It gave me an error:
error: using bridging headers with framework targets is unsupported
But why did that come up? I mean it's the same code on the slightly different versions of Xcode (13.1 versos 14.1) but I doubt there was a massive change between the two that would cause this. I want to be able to pass these app later in the future without having to care about this stuff. I made a GitHub (link below) would cloning that work? Also the laptop I chose was just a fresh reset. Would it be due to not having coco-pods installed?
I feel like I could go through and fix it all on that laptop and document that but then I'm afraid that every time I put it on a new one it would come up with random errors every single time making my documentation moot.
https://github.com/AbdullahMSaid/SonicExperiment-Works
With big help this was Fixed.
Things that fixed it.
Having the correct version of Xcode
Turning everything from absolute path to relative
Lots of other code fixes. But those are my project specific.
You don't need bridging headers in framework. Use should have something like "YourFramework.h" where you can import your .h files.
I am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael
I am using an fmod plugin for Unity3D. Compiling to Windows and OSX is fine because I can dynamically load the DLL/dylib.
The problem comes when I compile for iOS. I use
[DllImport("__Internal")]
Because iOS requires statically linked libraries. When I compile though I get a
SystemException: Duplicate native method found : FMOD_System_CreateSound. Please check your source carefully.
I am quite sure I don't duplicate the symbol. I think this might be due to the fact that Unity imports FMODs itself and that the two might be colliding... But if this is the case, I am surprised that FMOD_System_CreateSound is the first one to get caught. Is there a way around this? thx!
As always, I will be happy to provide any additional details!
Here is a sample project that will cause the error:
Sample Unity Project with FMod
EDIT:
The conflict was caused by iOS not allowing functions to have the same name even though they don't have the same signature. After removing the same-named functions (thus removing some FMOD features that I didn't need), I can compile to iOS, but as expected, I still get an error when Initializing because FMOD is already initialized by Unity.
Unity3d already has a limited version of FMOD that is bundled with it, which is causing the conflict you are seeing. Unfortunately, it doesn't seem possible to disable it at this time, so that you can use the full version of FMOD
In reference to your edit and after looking at the sample, it is true that you cannot have two methods of the same name as the compiler will not recognize which to link to.
The easy fix is to obviously name them differently.
As for the initialization, if you can access the FMOD that Unity 3D already created, then you don't have to reinitialize it.
I assume that a pointer to that object will be sufficient to remove the duplicate initialization. Hope this is clear.
I've set up VES and am modifying the Kiwiviewer app in XCode 4.3.2. Kiwi builds and runs fine, so I'm now trying to set up Sudzc within my app (it works fine standalone). I've followed the tutorial here but at the point after modifying the headers, where his app builds and runs, mine instead comes up with a succession of errors. At first, it gives >150 errors all along the lines of:
Lexical or Preprocessor Issue
Invalid token at start of a preprocessor expression
Mostly pointing at the line
#include "xmlversion.h"
in a file tree.h, which is a part of vtkmodular/Utilities/vtklibxml2/include/libxml/tree.h.
Changing the " " to < > (which was suggested for a similar problem) instead gives another Lexical or Preprocessor Issue, this time that 'xmlversion.h' file not found - seemingly all in the file tree.h. The file's in my Project Navigator (and cmd-clicking on #include "xmlversion.h" does indeed load the file, so it understands it that way).
Presumably then the problem is with vtk having its own version of libxml2? If this is the case - what can I do about this? All of the errors I've looked at seem to originate from within soap handler classes, and eventually get through to "include < libxml/tree.h>" - which is then in the vtk directory shown above. I'm not really sure where to go from here - is it wrong to include the library that's added in the instructions? Can/should I modify the header paths? If this isn't the tree.h the rest of the code is looking for, where is it - a quick system search didn't find it?
Or am I completely off the mark?
Thanks in advance!
I got an answer from the VES Mailing List, link here. It ended up being as simple as removing the VTK version of libxml2, which it seems VES doesn't use. Hope this might be of use to someone!
Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.