I'm trying to get the brother printing sdk working in my Xamarin project (I've got android working, but iOS sdk v3.1.9 is failing.)
I tried to use Objective Sharpie initially but what it produced is HUGE and contains lots of invalid characters and unnamed variables. (The files it produced are here)
I then tried to manually create the ApiDefinition.cs and Structs.cs files, (only a few methods to start with just to see if I could get it to work at all.)
The BrotherPrintIOS project compiles, but it has a warning: "The referenced component 'Native References/BRPtouchPrinterKitW.framework' could not be found."
When I try to import the class in my PrintTest.iOS project it can't find the namespace I defined in ApiDefinitions.cs
I also had problems importing the Native References. Since I'm compiling all this on a Windows computer running Visual Studio I had to unzip the SDK using Windows' built in "extract to" option, (I also tried 7-Zip with the same result.) When I did this it broke the link files to Headers, Resources, BRPtouchPrinterKitW, and Versions/Current. I ended up copying the files that were being referenced into the locations of the links. This seemed to let Visual Studio import the reference, but might be causing the build to not find them.
Related
I recently updated to the latest version of XCode and Xamarin Xamarin.iOS 10.0.0.1 (29910bb) running Visual Studio Professional 2015 Version 14.0.25431.01 Update 3. Both my Mac (build machine) and PC are fully up to date. Now that i have update i am no longer able to compile/build for anything but the simulator.
Compiler Error.
> C:\Program Files
> (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(1028,3): error :
> Failed to read file attributes for
> "/Users/mod/Library/Caches/Xamarin/Resources/Images.xcassets"
As a test i copied the solutions file over to the build machine and with no modifications it compiles and runs any of the targets.
I have also tried deleting the builds directory on the build machine and no help.
Anyone know what the work around is for this?
I have come across is this issue and what seems to possibly be related to on Xamarin Forums. The thing I found in my case was related to image assets within a library I was trying to use. I was able to remove the image assets and relocate to main project and that seemed to resolve the build issue.
This problem, like you have found is very recent. For what's it worth, I have also found that command line tools have numerous issues as they seem to lag behind the GUI provided in either Xamarin Studio or Visual Studio.
Good luck
As mentioned here I had to delete the folder ~/Library/Caches/Xamarin/mtbs/builds on the Mac used for the builds.
After a rebuild it worked again.
I have a native Win32 project written in C and wanted to visualize my project's dependencies from external DLLs. Visual Studio 2012 and 2013 let me generate a code map which would not only show all my functions and their dependencies from each other using arrows, but also all external libraries I used, which functions I used from those and which of my functions called which external functions etc..
Now, in Visual Studio 2015, this latter part seems to be missing. I can not get Visual Studio to show my project's external dependencies. I only see the internal ones. So here's my questions: Am I missing something? Do I have to activate a specific option in my project settings? Or are those external dependencies just not working in Visual Studio 2015 right now?
Steps to reproduce: Create a new non-empty Win32-project. In the Architecture menu, select Generate code map for solution. You will only see Win32Project1.exe in the middle of the screen. Meanwhile, Visual C# seems to be fine, showing the external dependencies. Create any C#-project for comparison.
Thank you for taking the time to post this! This looks like a regression, as in Visual Studio 2013 an Externals group with external dependencies is shown for C++.
I've logged a bug on Microsoft Connect so that you're able to track this externally:
https://connect.microsoft.com/VisualStudio/feedback/details/1694695
I have posted this workaround on the link that Bogdan Gavril listed and hope it helps someone. Unfortunately, it requires that you enable "CLR" support for your project. Basically, it appears that the VC++ linker and librarian is looking for a flag that indicates some type of managed code. At the very least, the code map is dependent on the mscorlib.dll reference injection. To make the CLR issue (which adds a lot of unnecessary bulk for native code) less a problem, simply create a new build configuration for use only when you need code maps with external dependencies. Make sure you've selected "CLR Support" on the general options of the project properties configuration page. Then, clean (probably not necessary) your solution and generate a code map. You will find the external dependencies as expected!
Zac
I am attempting to convert the Microsoft.Health C# class library that is installed as part of the HealthVault SDK, using instructions provided here. After following these instructions, I get the following error when attempting to load the project into Visual Studio 2013.
"The project is targeting frameworks hat are either not installed or
are included as part of future updates to Visual Studio. See
http://go.microsoft.com/fwlink/?LinkId=287985"
Visiting the link takes me to .NET SDKs and Downloads. Once there, I have no clue on what needs to be done.
I do realize that one will have to leverage the Portable Class Library Contrib project to fill in some missing bits, especially code related to System.Security. This, I will deal with later.
Any one run into a similar problem?
Maybe so late but for those who have the same problem.
I had the same error in a project which was working perfect before updating VS2013 and finally after 3 hours looking for the source of the error I found that the error is about TargetFrameworkProfile.
In my case I sloved it like so:
Right click in the unloaded project in your solution and click Edit.
Find the TargetFrameworkProfile tag and set it as below:
<TargetFrameworkProfile>Profile78</TargetFrameworkProfile>
At a guess, this is because you need to specify the TargetFrameworkVersion and TargetFrameworkProfile properties in the project file. Compare the .csproj you are trying to create to a newly created PCL project file, and make sure that everything that's not specific to your project matches.
I ran into the same issue and got it resolved by installing the latest Visual Studio Update
I have a Visual C++ library which I want to compile for a certain platform (I try to compile POCO for a Win CE ARM platform, but that might not be relevant to this question). I got a vendor-specific Windows CE SDK (including all common Windows include files e.g. winbase.h) which is set as target platform within the Visual Studio project files. However, when I compile the program, I can see from the error log that the default Windows 6.0A SDK is used, resulting in a bunch of compilation errors.
I guess the WindowsSdkDir ist not set accordingly - I thought this would be automatically overriden when setting the target platform within Visual Studio.
So my question is: can I modify the WindowsSdkDir for a single project explicitly?
Thank you in advance
Which CE version, which VS version and on which Windows version? I know that I had problems installing CE5 and/or CE6 SDKs and getting them recognized by Visual Studio 2005 running on Windows 7 (64 bit). I don't remember the exact symptoms and fix, but you can test that by simply creating a smart device project for the target SDK.
If that is not the issue, there is also the pitfall with the target in both the project file (.vcproj) and the solution (.sln). You can change both independently from each other, up to the point where you compile the x64 debug version of a project in the win32 release version of the solution. Verify that these setting match.
Then, if you adjusted the .vcproj file to use your target platform (for which I personally would use a text editor), things should work. If you need to adjust the build or some paths, you can sometimes get by with e.g $(Platform) in the compiler/linker settings.
Lastly, if all that doesn't work, there are property sheets, which can adjust certain settings. You then create a property sheet once and then load it into the project that you want to compile. I'm not sure if you can change the target platform or the SDK paths with that approach though, and I'd rather try to find out why the SDK doesn't work and how to fix it instead.
I am working on a C++/CLI project with VS 2012 in Dynamic Library (.dll) and x64 mode.
If I switch the mode to Static Library, I get the error below.
Error 1 error C1107: could not find assembly 'mscorlib.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable C:\Depot\Main\Current\Sln\ALibraryProject\Stdafx.cpp 1 1 ALibraryProject
I tried removing the reference to the mscorlib.dll then adding it again from:
Project > Properties > General > Common Properties
But that didn't help. As I know that VS handles the reference to the .NET assemblies, I don't want to add a disk file reference to it as it seems illogical! Did anybody face this before?
I had the same problem when converting my solution from the VS2010 compiler to VS2013 compiler.
I resolved it by changing the project settings (for the project containing the managed .cpp file that was throwing this error) as follows: In Project Settings | C/C++ | General | Additional #using Directories I added the macro $(FrameworkPathOverride). This resolves to the reference assembly directory for the version of .NET that you're targeting, which in my case is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.1
If I switch the mode to Static Library
This is not the typical error you get when you try to build a static library with /clr in effect. I'd have to assume you've been tinkering with project settings to get rid of the inscrutable linker errors you get when you try to do this.
Core issue is that the C++/CLI build system doesn't support static libraries that contain MSIL. Managed code doesn't use a linker, binding happens at runtime. Which makes the essential difference between static libraries and DLLs disappear. So Microsoft decided to not support it because it didn't make much sense to implement it. Unfortunately they don't yell loud enough when you try to do it anyway, the linker errors you get don't give enough of a hint what you did wrong. Workarounds, like merging with ILMerge don't work either, it cannot deal with mixed-mode assemblies. Merging the native code sections and their associated relocation table entries is very untrivial.
Keep in mind that it is fine to link native static libraries. A typical C++/CLI project has only the ref class wrappers that need to be built with /clr in effect. You can glue any amount of native code from libraries into the final assembly.
I'm forced to theorize about the actual compile error, too many programmers get this error for another reason that doesn't have anything to do with building static libraries and they are harassing me in the comments.
Do beware that targeting a different version of .NET than the one you have installed on your machine is quite a hazardous affair, particularly so if you want to target 4.0 and you have 4.5.x installed. The key element in your .vcxproj file is the <TargetFrameworkVersion>. This will be missing if you started the project targeting an old .NET version, you have to insert it yourself. The IDE also doesn't support changing it if it is present, again edit by hand.
Which is enough to coax MSBuild into generating the proper compile command. You can verify if that panned-out well, look in the *.tlog subdirectory of the Debug build directory for your project. The cl.command.1.tlog file shows the options that were passed to the compiler. It should contain:
/AI"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
/FU"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\mscorlib.dll"
Note the subdirectory, very important that it matches your intended .NET target. v4.0 in this example. And very, very important that it does not point to c:\windows\microsoft.net, the legacy location for reference assemblies.
I have the same problem. Having a dll doesn't work, as I need to provide a native C++ wrapper for a .net object so it can fulfil a natice c++ interface - I can't use .net in a dll interface - this gives a compile error
This worked as a static library in VS 2010 (with .net 4)
Some of my executables and dlls which also have some code with /clr. They don't have an issue. I'm not trying to make a net Lbirary.
I solved it by removing dependency in old and not updated mixed lib, which was also configured only in Debug configuration, and as result, it started to get the same error as yours after I changed some code.
It was not simple to find it, because error is not clear, and the dependency was set up via "Additional Dependencies" in project settings.
Open visual studio and unload your project then Go to the project folder and open file .vcxproj . Search for tag "targetFrameworkVersion"
(if not present it means ur project is not using dot net frameworks.so no requirement of change)
Change it to required version
Save the file.
And now reload the project .