I created an empty ASP.NET project and added the following T4 template to it:
<## template debug="false" hostspecific="false" language="C#" #>
<## assembly name="System.Core" #>
<## assembly name="Newtonsoft.Json.dll" #>
<## assembly name="Microsoft.Spatial.dll" #>
<## output extension=".txt" #>
I also added NuGet packages Newtonsoft.Json and Microsoft.Spatial. After I compile this project using Visual Studio 2013, I can edit the template file and when I save it the output is correctly generated.
However, if I load the same project into Visual Studio 2015 RC, then the attempt to save the template file result in the following error:
"Compiling transformation. Metadata file 'Microsoft.Spatial.dll' could
not be found."
Note that it's only Microsoft.Spatial.dll that causes the error, Newtonsoft.Json.dll is accepted. And if I prefix Microsoft.Spatial.dll with "$(ProjectDir)bin" then it is accepted.
I would like to avoid using path prefix (because the location of the DLL depends on the project type that I have no control of), but what puzzles me most is why one DLL from a NuGet package can be specified without path prefix, while another DLL causes a failure.
Related
I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3
I am attempting to compile the HubBrowser project - which is an example Caliburn Micro Xamarin project (one of the very few there are).
Its a great example but the Android project is not compiling. I get the following errors:
Error 8 The type or namespace name 'CaliburnApplication' could not be found (are you missing a using directive or an assembly reference?) HubBrowser\HubBrowser.Android\Application.cs 14 32 HubBrowser.Android
Error 7 The type or namespace name 'ActivityLifecycleCallbackHandler' could not be found (are you missing a using directive or an assembly reference?) HubBrowser\HubBrowser.Android\Services\ApplicationNavigationService.cs 12 26 HubBrowser.Android
Error 9 The type or namespace name 'ActivityEventArgs' could not be found (are you missing a using directive or an assembly reference?) HubBrowser\HubBrowser.Android\Services\ApplicationNavigationService.cs 24 55 HubBrowser.Android
Error 10 The type or namespace name 'ActivityEventArgs' could not be found (are you missing a using directive or an assembly reference?) HubBrowser\HubBrowser.Android\Services\ApplicationNavigationService.cs 29 54 HubBrowser.Android
What is the cause of this error and how can I fix it?
I have made sure my references point to Caliburn.Micro and Caliburn.Micro.Platform (net45 versions). Do I need Caliburn.Micro.Portable.Core? If so where is this dll? Installing C.M through NuGet always fails - these NuGet packages and PCL's are and ABSOLUTE nightmare.
You need to use the pre-release 3.0 beta package. In the Core PCL project, install Caliburn.Micro.Core 3.0.0-beta1, and in your Android project, install Caliburn.Micro 3.0.0-beta1 (which will also install Core as a dependency).
Be sure to check the "pre-release" checkbox in the Nuget dialog or else you won't see the beta releases.
I am trying to generate documentation with sandcastle help file builder. While building the project in the sandcastle i am getting the following error.
MRefBuilder : error : Unresolved assembly reference: Microsoft.Owin (Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) required by Microsoft.AspNet.Identity.Owin [C:\Users\inkosah\Documents\Help\Working\GenerateRefInfo.proj]
Last step completed in 00:01:19.4610
Can anybody help me to resolve this issue? I also tried adding it separately to project references in the sandcastle but no help.
Solution 1 : Add missing references to a dummy project.
Create 'dummyProject' (ie class library)
In Visual Studio - Package Manager Console
Install-Package Microsoft.Owin -Version 2.1.0.0 -ProjectName dummyProject
Install-Package Microsoft.Owin.Security.OAuth -version 2.1.0.0 -ProjectName dummyProject
In Sandcastle Help Fil Builder - Project Explore, add two references
Microsoft.aspNet.identity.Owin (dll found in ..\packages\Microsoft.AspNet.Identity.Owin.2.2.0\lib\net45)
Microsoft.Owin (dll found in ..\packages\Microsoft.Owin.2.1.0\lib\net45\Microsoft.Owin.dll)
It looks like MRefBuilder found that Microsoft.AspNet.Identity.Owin relies on Microsoft.Owin (== v 2.1.0) and not Microsoft.Owin (>= 2.1.0).
The main project is still using Microsoft.Owin 3.0.1.0
Solution 2 : Ignore unresolved references
In Documentation (or SHFB) Project Properties / Plug-Ins :
Add "Assembly Binding Redirection" in "Plugs-Ins in This Project"
configure it to "ignore if Unresolved" "Microsoft.Owin" and "Microsoft.Owin.Security.OAuth"
I have problem with building my solution by MSBuild.
In my solution I have the F# projects to which I have added the AssemblyInfo.fs files, such file looks as follows:
namespace namespaceName
open System.Reflection
open System.Runtime.CompilerServices
open System.Runtime.InteropServices
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[<assembly: AssemblyTitle("assemblyName")>]
[<assembly: AssemblyDescription("")>]
[<assembly: AssemblyConfiguration("")>]
[<assembly: AssemblyCompany("")>]
[<assembly: AssemblyProduct("assemblyName")>]
[<assembly: AssemblyCopyright("Copyright © 2013")>]
[<assembly: AssemblyTrademark("")>]
[<assembly: AssemblyCulture("")>]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[<assembly: ComVisible(false)>]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[<assembly: Guid("9b60cdeb-57b8-4e08-b713-1be614a449cd")>]
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the ‘*’ as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[<assembly: AssemblyVersion("1.0.0.0")>]
[<assembly: AssemblyFileVersion("1.0.0.0")>]
()
When I compile my solution in Visual Studio 2012 I do not have any problems. All assemblies are build with a nice information about version.
The problem is with the TFS Builds (I have the TFS 2012). The build of my solution always fails. The error origins in the CoreCompile fsc.exe step and it is about the AssemblyInfo.fs file:
Project "D:\path\projectMaster.csproj" (40) is building "D:\path\projectName.fsproj" (41) on node 1 (default targets).
PrepareForBuild:
Creating directory "obj\Release\".
Creating directory "bin\Release\".
GenerateTargetFrameworkMonikerAttribute:
Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
CoreCompile:
C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\fsc.exe -o:obj\Release\projectName.dll --debug:pdbonly --noframework --define:TRACE --doc:bin\Release\projectName.XML --optimize+ -r:D:\path\r1.dll -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp\3.0\Runtime\v4.0\FSharp.Core.dll" -r:D:\path\r2.dll -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.dll" -r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Numerics.dll" --target:library --warn:3 --warnaserror:76 --fullpaths --flaterrors --highentropyva- "C:\Users\userName\AppData\Local\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.fs" folder1\file1.fs folder1\file2.fs folder2\file1.fs
D:\path\projectName\AssemblyInfo.fs(37,10): error FS0010: Unexpected symbol ':' in expression. Expected ']' or other token. [D:\path\projectName\projectName.fsproj]
D:\path\projectName\AssemblyInfo.fs(37,1): error FS0598: Unmatched '[' [D:\path\projectName\projectName.fsproj]
D:\path\projectName\AssemblyInfo.fs(40,1): error FS0010: Incomplete structured construct at or before this point in implementation file [D:\path\projectName\projectName.fsproj]
Done Building Project "D:\path\projectName\projectName.fsproj" (default targets) -- FAILED.
I have no idea why the fsc.exe in MSBuild have problem with my AssemblyInfo.fs files.
What is more strange, when I use the "Developer Command Prompt for VS2012" and I execute exactly the same MSBuild or fsc.exe commands everything goes fine. I do not have any errors. So it seems that the TFS Build have some strange problems which I am not able to reproduce on my machines even if I run the same commands.
Thank you for any help!
I need to compile a mex file which is written in C++ (VS 2008) with Matlab 2009. If I compile with VS 2008 directly, it seems Matlab is not compatible and the error is:
//Invalid MEX-file
So I tried to comile with Matlab directly using MEX function. In "mex -setup" I chose
//Lcc-win32 C 2.4.1 in C:\PROGRA~1\MATLAB\R2009a\sys\lcc
to compile with Matlab, but it only compile C and not C++ and my codes are in C++.
Then I chose
//Microsoft Visual C++ 2008 SP1 in C:\Programme\Microsoft Visual Studio 9.0
to compile with VS 2008 from Matlab. For a simple test C++ file it worked. The mex file was perfect. Then I added some header files and a function to call a class in one of the header files. I added "Aria" header files to my project and the above error comes.
//Aria website where you can find header files: (http://robots.mobilerobots.com/wiki/ARIA)
Header files are in the same directory as main program, all the lib files are defined in VC++ project. In "Additional library directories" I added their path again. When I build my project through VC++, there is no error. But when I try to use MEX from Matlab, this error happens. (the name of C++ file is "test")
//
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
...
test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void _cdecl Aria::init(enum Aria::SigHandleMethod,bool,bool)" (_imp_?init#Aria##SAXW4SigHandleMethod#1#_N1#Z) referenced in function _main
test.mexw32 : fatal error LNK1120: 1 unresolved externals
C:\PROGRA~1\MATLAB\R2009A\BIN\MEX.PL: Error: Link of 'test.mexw32' failed.
??? Error using ==> mex at 218
Unable to complete successfully.
//
To test the project, I wrote a small class in one of that header files and used that class in C++ file, and it worked! I do not know why other classes do not work. They are linked to each other and they are about 140 .h files.
Has anyone any idea why this happens?
Why there is no error when I build, release and debug project in the VC++, but when I try to compile MEX file with Matlab, this error?
All the header files and necessary libs needs to be compiled.
//mex name.cpp name.h name.lib
Here, WinMM.Lib, WSock32.Lib and AdvAPI32.Lib.