Is there any way to avoid building all the references of a dll in order to simulate a "Build Only" for managed dlls?
If you read the file %ProgramFiles(x86)%\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets, you'll find that building of referenced projects inside the target ResolveProjectReferencesis conditional on the property test '$(BuildPassReferences)' == 'true'.
If you set this property to false on MSBuild invocaton, references will not be rebuild:
msbuild ... /properties:BuildPassReferences=false,...
Note that this is not a supported feature, and that your compilation will likely genuinely fail if outputs of the referenced projects do not exist. Unlike C++ using include files to resolve external references, managed compilation needs existing reference DLLs.
So the answer is yes it is possible, not supported, and a clear step on the way into a trouble, unless the end you are trying to achieve is very specific and narrow.
Related
In my Xamarin.iOS project I need to reduce the assembly size (Apple's requirement for AppStore applications), and I need to turn on linker, setting the linker behavior either to "Link Framework SDKs only" or "Link All".
When I've selected "Link Framework SDKs only" in Linker behavior I get the compilation error upon building the project:
Can't resolve the reference 'System.Void System.Data.SqlClient.SqlCommandBuilder::DeriveParameters(System.Data.SqlClient.SqlCommand)',
referenced from the method 'System.Void DevExpress.Xpo.DB.MSSqlConnectionProvider::CommandBuilderDeriveParameters(System.Data.IDbCommand)'
in 'System.Data.SqlClient, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
To fix this issue all answers I have found recommendation to turn "Link All" option in the Linker behavior option.
When I've selected "Link All", the project compiles okay, but at the runtime I get system exception on the IoC Container code (type AAA does not implement the interface BBB), because I use reflection, and linker with "Link All" options affects the code with the reflection. And as far as I know this linker option (Link All) is not recommended for the projects where reflection is being used.
What options do I have at this point?
Linker configuration
I suspect your best option is to look at define a configuration file to tell the Linker what must be kept. There is a good set of documentation on Microsofts documentation site.
There are some other options but may not strictly apply in this case or you may wish to use a combination.
Preserve Attribute
You can provide extra definitions to the linker to ensure the type, methods and/or fields are not eliminated from your application. In your own code the preferred way is to use the [Preserve] custom attribute, as discussed in the Linking on iOS and Linking on Android guides.
Linking for each platform is certainly a possibility however I suspect that you want to preserve things in your shared project which is why I think the config file will be right for you.
This approach gives you the ability to define at varying levels (e.g. assembly or class level to keep everything or down to individual properties/methods, etc.).
Actually reference the bits you need kept
I dislike this option very much but some people find it quick and easy to either prove you can keep parts of the code or just accept it is a solution.
You essentially create a class of actual references to the methods/properties that you want to be kept.
public class LinkerPleaseInclude
{
public void Include(MyType arg)
{
arg.MethodIDontWantRemoved();
}
}
Note I have sourced some details from this site
I want my Framework 4.7.2 code to use a library that targets netcoreapp3.1
Nuget indicates that the library is referenced, yet I do not see it in the list of references.
I tried editing the project to change the TargetFrameworkVersion from
<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
to
<TargetFrameworkVersion>v4.7.2;netcoreapp3.1</TargetFrameworkVersion>
But saving this change causes a message
And I cannot re-load the project
I tried chainging to
<TargetFrameworkVersion>netcoreapp3.1;net472</TargetFrameworkVersion>
The build error becomes
Error The expression "[Microsoft.Build.Utilities.ToolLocationHelper]::
GetPathToStandardLibraries(.NETFramework, netcoreapp3.1;net472, '', '', '', '')"
cannot be evaluated. Input string was not in a correct format.
I asked a related question to try and troubleshoot this.
I think your looking for <TargetFrameworks>
so in this case:
<TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks>
Please note you need a SDK-style csproj. I assume this in the case for you. If not, check How to upgrade csproj files with VS2017
See also the article about <TargetFrameworkVersion>:
This article shows the old way to specify a target framework. SDK-style projects enable different TargetFrameworks like netstandard. For more info, see Target frameworks.
I have a VS 2010 modeling project with a layer diagram. I use the layer diagram to validate some assemblies. Note that I am adding assembly referenced to the modeling project, not project references, due to some build constraints I have. This works fine as long as the referenced assemblies can be found. When an assembly is not found, the build passes but a warning is issued indicating that a referenced assembly is not found. This makes perfect sense. However, if you expect the build to fail when there is a layer diagram validation error, a passing build gives the false impression that the implementation in the assembly was valid. My question is, how can I make the build fail when a referenced assembly is not found. I tried the TreatWarningsAsErrors tag but that did not work. I am not an MSBuild expert, but I think modeling projects work a little differently in that respect.
Thanks in advance for replies.
Fuat
You could alter the beforebuild target to have something like:
<Error Condition="!Exists('C:\Reference\Required.dll')" Text="Reference not found" />
I am using VS2010 Express and just installed Boost v1_47. I have added the 'include' folder to 'additional include folders' option, and also the 'lib' folder to the 'additional libraries' option in VS.
Then, I included boost/regex.hpp in one of my files, but actually wrote no code using boost yet. However, when building the solution I get lots of error messages, coming in two flavours:
Redefiniton errors, such as:
1>D:\boost\boost_1_47\boost/detail/interlocked.hpp(83): error C2373: '_InterlockedCompareExchangePointer' : redefinition; different type modifiers
1> C:\Program Files\Microsoft SDKs\Windows\v7.1\include\winnt.h(2597) : see declaration of '_InterlockedCompareExchangePointer'
Invalid calling convention errors (lots of these), such as:
D:\boost\boost_1_47\boost/regex/v4/regex_traits_defaults.hpp(271): error C3641: 'boost::re_detail::global_lower' : invalid calling convention '__cdecl ' for function compiled with /clr:pure or /clr:safe
Note: I haven't explicitly included winnt.h in any of my source/header files, and have tried de-activating pre-compiled headers and removing the stdafx.h includes, but it didn't solve the problem.
What's going on?
Thanks in advance
You have to make sure that you compile your program with the same settings as boost.
It seems like you used the wrong project template (CLR something) to create your application project.
You could try to modify the properties of your existing project to make it compatible with boost, but the CLR ... projects have lots of incompatible property values set by default, so i think the easiest way would be to create a new project from scratch (and import your existing code).
You should use the "Empty Project" template and create a new project, and then add your existing source and header files to it, and add the boost include path again, and add any required boost .lib files to Project Properties > Linker > Input > Additional Dependencies (Most boost libraries work out of the box without adding anything to linker inputs because they are header only, so you might not need to add any .libs).
Boost is a C++ required, designed to be consumed by C++ code, not C++/CLI code, thus it can only be used with native C++ classes, and most boost headers will produce headers when included in a source file which contains C++/CLI code.
In a project I'm working on FxCop shows me lots of (and I mean more than 400) errors on the InitializeComponent() methods generated by the Windows Forms designer. Most of those errors are just the assignment of the Text property of labels.
I'd like to suppress those methods in source, so I copied the suppression code generated by FxCop into AssemblyInfo.cs, but it doesn't work.
This is the attribute that FxCop copied to the clipboard.
[module: SuppressMessage("Microsoft.Globalization",
"CA1303:DoNotPassLiteralsAsLocalizedParameters",
Scope = "member",
Target = "WindowsClient.MainForm.InitializeComponent():System.Void",
MessageId = "System.Windows.Forms.Control.set_Text(System.String)")]
Anyone knows the correct attribute to suppress this messages?
PS: I'm using Visual Studio 2005, C#, FxCop 1.36 beta.
You've probably got the right code, but you also need to add CODE_ANALYSIS as a precompiler defined symbol in the project properties. I think those SuppressMessage attributes are only left in the compiled binaries if CODE_ANALYSIS is defined.
In FxCop 1.36 there is actually a project option on the "Spelling & Analysis" tab that will supress analysis for any generated code.
If you don't want to turn analysis off for all generated code, you need to make sure that you add a CODE_ANALYSIS symbol to the list of conditional compilation symbols (project properties, Build tab). Without this symbol defined, the SupressMessage attributes will be removed from the compiled code so FxCop won't see them.
The other problem with your SuppressMessage attribute is that you are listing a "Target" of a specific method name (in this case WindowsClient.MainForm.InitializeComponent():System.Void) and listing a specific "Scope". You may want to try removing these; otherwise you should add this SuppressMessage to each instance of the method.
You should also upgrade to the RTM version of FxCop 1.36, the beta will not automatically detect the newer version.
Module level suppression messages need to be pasted into the same file as the code that is raising the FxCop error before the namespace declaration or in assemblyinfo.cs. Additionally, you will need to have CODE_ANALYSIS defined as a conditional compiler symbols (Project > Properties > Build). Once that is in place, do a complete rebuild of project and the next time you run FxCop the error should be moved to the "Excluded in Source" tab.
Also, one small tip, but if you are dealing with a lot of FxCop exclusions it might be useful to wrap a region around them so you can get them out of the way.