Pasted the following into a exe.manifest file for a VS10 Win32 project from code found here:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
Building generated the linker warning:
warning 81010002: Unrecognized Element "longPathAware" in namespace "http://schemas.microsoft.com/SMI/2016/WindowsSettings".
Understandable, based on the age of the bundled mt.exe as explained in this similar issue.
Question is, will this in any way affect the long path awareness of the application on a platform where the attribute is known?
Downloaded the 2.4 Gb W10 SDK, thanks to Sera's suggestion, and copied the 1 mb file mt.exe over to Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin. Warning not generated with the new mt. (Minor issues with the Environment variables set for the 7.1 SDK in Program Files\Microsoft SDKs\Windows\v7.1\Bin added in some extra flavour and texture to the operation)
Another way is to disable manifest generation in the projects linker options and manually create an external manifest. It must be named like "YourApplication.exe.manifest" and be located next to "YourApplication.exe".
I had to copy the manifest via post-build event as VS always deleted the manifest when doing a clean build.
Related
When I try to build the application I get an exception the following exception :
C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(681,3): error : Failed to resolve assembly: 'Java.Interop, Version=0.1.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
I tried cleaning the project and building it again, also updated the Xamarin.Forms packages but still with no luck.
A little overview on the stack trace :
2>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(681,3): error : Failed to resolve assembly: 'Java.Interop, Version=0.1.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
2> Tool /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/bin/mtouch execution finished. (TaskId:153)
2> MTouch: 2016-07-05T14:27:15.8191415+05:30 - Finished (TaskId:153)
2> Output Item(s): _NativeLibrary= (TaskId:153)
2>Done executing task "MTouch" -- FAILED. (TaskId:153)
Has anyone received this error? I am running the latest Xamarin for Visual Studio.
As mentioned in the comments above by #SushiHangover Java.Interop.dll is from Xamarin.Android and I was getting an error in Xamarin.IOS.
I had a reference of Mono.Android in PCL which is always referenced in Xamarin.IOS so indirectly I was referencing dll of Xamarin.Android to Xamarin.IOS. Removing the reference from PCL solved my problem.
Step-by-step instructions on how to fish this one out, as it took me some time to find where the 'Android polluted' peace of code was.
Unload your Common code project
Open .csproj look for something like this
<ItemGroup>
<Reference Include="Mono.Android">
<HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\MonoAndroid\v11.0\Mono.Android.dll</HintPath>
</Reference>
Delete this segment from csproj.
Load the project
Clean and rebuild the solution having iOS as startup Project, at this point, you will get a build error that will show which .cs file fails to build due to missing reference.
Go there and move the mechanism to an Android specific project.
As mentioned by #AkashAmin 'Mono.Android' referenced should not be there in PCL project.
But with this, also make sure that you have not added any 'Android' specific code in PCL project by adding 'using Android', if this was done then you need to remove this code by using 'Dependency Services', Click here
I had the same problem and when I removed the android.mono reference from pcl project it worked fine.
I think it happens because we are building project in ios and it doesn't have any android libraries
Platform specific code within the Shared Project will cause iOS compiler to attempt to use the platform specific assemblies when compiling.
In my case, I had a reference within my Shared Project's code, within the "using" statements, which was causing iOS to attempt to link to Android specific assemblies.
Removing the code from the Shared Project allowed for successful compiling of the project.
Just in case, I got this error from working with ReSharper on VS2013 (https://bugzilla.xamarin.com/show_bug.cgi?id=41627).
What I did was use the Workaround to explicitly add java.interop.dll assembly to my project. This problem doesn't affect Build so you can deploy first and VS will download java.interop to your app's obj\Debug\linksrc folder, which you can reference...
You need to check your PLC project on Android link. In PLC project ctrl+f and lets go find "Android" and delete it.
When i am trying to Build my default JavaScript project(BlankApp Apache Cordova) in Visual Studio 2015 preview am getting following error.
The TypeScript Compiler was given no files for compilation, so it will skip compiling.
Steps Taken in visual studio 2015 preview:
File -> New -> Project -> Apache Cordova apps(under Javascript templates).
Run the default project with Android Emulator.
Getting the following error.
Warning 2 The TypeScript Compiler was given no files for compilation, so it will skip compiling. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript\Microsoft.TypeScript.targets 97 5 BlankCordovaApp4
This is a known issue in the CTP3 release. It sounds like you've created a JS-based project, and have not added any TypeScript files, and so of course there are no .ts (aka TypeScript) files passed to the compiler. Ideally the compiler wouldn't be run at all, but the warning is harmless, and everything else should otherwise be working.
You need to make sure that at least one of your TypeScript files is marked with the TypeScriptCompile build action.
If you click on the file and check the properties window in Visual Studio you will see the build action - it may be that they are all set to some other action.
Option 1:
Take Project offline, edit project, remove the following lines:
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props"
Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')"/>
and
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets"
Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')"
/>
Option 2:
Change "AddTypeScriptReferencePath": true to false in Webessentials-Settings.json
It seems that there is no type script file available to compile. add a blank type script file under script folder and then compile, it should work.
This warning was driving me nuts with ASP.NET 5 (asp.net core 1). If you double click the warning you open the Microsoft.TypeScript.targets file. Delete the line with CompileTypeScript and the warning goes away. I'm assuming this prevents TypeScript from compiling normally, which is fine by me as I don't want it anyway.
<PropertyGroup>
<CompileDependsOn>
CompileTypeScript; <--- delete this line
$(CompileDependsOn);
</CompileDependsOn>
I had the same issue.
Mine was due to missing system variable to nodejs. Check your visual studio output. If it is not recognizing “node” command, add system variable.
Computer->right click-> properties -> advanced system settings -> Environment Variable
Check “path” under user variables and system variables
Add the nodejs path to it. Ie: C:\Program Files (x86)\nodejs
I have a problem when trying to debug a simple PCL (Point-Cloud-Library Application) application in MS Visual C++ 2010 that has to visualize a point cloud. (This example: http://pointclouds.org/documentation/tutorials/pcl_visualizer.php)
I setup the C++ project with all the include and library folders needed for PCL.
I add to the linker input the following dependencies:
openNI.lib
libboost_system-vc100-mt-gd-1_49.lib
libboost_filesystem-vc100-mt-gd-1_49.lib
libboost_thread-vc100-mt-gd-1_49.lib
libboost_date_time-vc100-mt-gd-1_49.lib
libboost_iostreams-vc100-mt-gd-1_49.lib
pcl_common_debug.lib pcl_apps_debug.lib
pcl_features_debug.lib
pcl_filters_debug.lib
pcl_io_debug.lib
pcl_io_ply_debug.lib
pcl_kdtree_debug.lib
pcl_keypoints_debug.lib
pcl_octree_debug.lib
pcl_registration_debug.lib
pcl_sample_consensus_debug.lib
pcl_search_debug.lib
pcl_segmentation_debug.lib
pcl_surface_debug.lib
pcl_tracking_debug.lib
pcl_visualization_debug.lib
vtkRendering-gd.lib
QVTK-gd.lib
vtkalglib-gd.lib
vtkCharts-gd.lib
vtkCommon-gd.lib
vtkDICOMParser-gd.lib
vtkexoIIc-gd.lib
vtkexpat-gd.lib
vtkFiltering-gd.lib
vtkfreetype-gd.lib
vtkftgl-gd.lib
vtkGenericFiltering-gd.lib
vtkGeovis-gd.lib
vtkGraphics-gd.lib
vtkhdf5-gd.lib
vtkHybrid-gd.lib
vtkImaging-gd.lib
vtkInfovis-gd.lib
vtkIO-gd.lib
vtkjpeg-gd.lib
vtklibxml2-gd.lib
vtkmetaio-gd.lib
vtkNetCDF_cxx-gd.lib
vtkNetCDF-gd.lib
vtkpng-gd.lib
vtkproj4-gd.lib
vtksqlite-gd.lib
vtksys-gd.lib
vtktiff-gd.lib
vtkverdict-gd.lib
vtkViews-gd.lib
vtkVolumeRendering-gd.lib
vtkWidgets-gd.lib
vtkzlib-gd.lib
OpenGL32.Lib
When i start debugging the IDE ends up with the following link error:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-sgd-1_49.lib'
The library "libboost_thread-vc100-mt-sgd-1_49.lib" is not contained in the set of boost library of the 3party folder of PCL. What am I doing wrong? Is there another path for VS2010 configuration for PCL programs?
Additional information:
I downloaded last version 1.6 of PCL, choosing the MSVC2010 version all-in-one.
I set up the code generation with /MTd (Multi-threaded debug)
I'm running the project with debug mode.
You already got libboost_thread-vc100-mt-gd-1_49.lib so enable your project to use dynamic linking in "configuration properties".
Another option is to download Boost and build it using static linking to generate the libboost_thread-vc100-mt-sgd-1_49.lib file. Don't forget to set the folder of "Linker" -> "Additional Library directories" to the location of the file.
I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.
I've just upgraded a project from VS2008 to VS2010 but I'm still targeting the 3.5 framework.
In my project file I have a custom task to run SGEN to generate my XmlSerializers.dll. However the version of sgen being run targets the 4.0 framework. As a result, when I run my application I get the error message:
"Could not load file or assembly 'XXXX.XXXX.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
The Sgen task looks like this:
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="#(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
</SGen>
</Target>
There's the ToolPath="$(SGenToolPath)". How do I make it run the version that targets 3.5?
There's a similar question here but it doesn't help me much.
I have solved this by manually configuring the ToolPath to point to the old (version 2.0.50727.3038) version of sgen.exe
On my machine, this is in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I changed the ToolPath attribute to be:
ToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
and this solved the problem.
It seems, by default, it's running the new 4.0 framework version in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
Hope this helps somebody else.
MSBuild uses the registry to get the path to the v3.5 tools. The MSBuild tasks that require v3.5 SDK tools will fall back to the v4.0 path if the path to the 3.5 tools can't be identified - look at the logic used to set the TargetFrameworkSDKToolsDirectory property in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.NETFramework.props if you're really interested.
You can diagnose and fix this problem as follows:
Install Process Monitor and set up a filter to monitor registry access by msbuild (Event class: Registry, Process Name: msbuild.exe, all types of result).
Run your build.
Search Process Monitor for a RegQueryValue access matching "MSBuild\ToolsVersions\4.0\SDK35ToolsPath". Note that this could be be under either "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" or "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft".
If you have a look at this key in the registry, you'll see that it aliases another registry value, e.g. "$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86#InstallationFolder)"
Shortly after this, you'll probably see a "NAME NOT FOUND" result. If you look at where the expected key should be, you'll see that they don't match the key being requested (missing hyphens and possibly no key ending with "-86").
It should be clear what you need to correct. I chose to export the incorrect keys, edit the .reg file and run it to create the correct keys.
One cause of invalid registry entries could be a bug with the Microsoft SDK v7.1 installation:
http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources
I found this to be the easiest way and it works with: <GenerateSerializationAssemblies>On</ GenerateSerializationAssemblies>
<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>
The problem is $(SGenToolPath) isn't set by MSBuild. If you use $(TargetFrameworkSDKToolsDirectory) then it will attempt to resolve the path based on $(TargetFrameworkVersion).
Its helpful to make use of tags for printf() style debugging. Add the following temporally.
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<Message Text="SGenPath: $(SGenPath)" Importance="high"/>
<Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
<Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>
#Craig - Did you manually install the 7.0A framework on your build machine. If so, your problem may be your registry settings and not msbuild. Take a look at LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath and make sure the reg key that is referenced there is valid. (Hint: Make sure the -x86 is there only if the -x86 key exists.)