We upgraded our .net 3.5 projects (c#) to .net 4.0. When you look at the project file there are two tags that I'm trying to make sense out of:
<RequiredTargetFramework>3.5</RequiredTargetFramework>
<TargetFrameworkVersion>4.0</TargetFrameworkVersion>
Why are there two seemingly similar tags with different values?
The <RequiredTargetFramework> element was already present in your 3.5 project. It's associated with the assembly <Reference> and only present on assemblies that are not available in .NET 2.0
I don't buy much stock in the single mention of it in MSDN, I don't see how batch building has anything to do assembly references. Nor is it used in any of the 3.5 MSBuild .target files. I think the IDE simply uses it to put the warning icon next to the reference in the References node when you change the Target Framework to a version less than what's needed to support the assembly.
There are other elements like this in a project file that don't affect MSBuild but have an effect in the IDE. Like <SubType> and <DependentUpon> in the <Compile> element.
Have you found this one link? link text. TargetFrameworkversion is easy, that's the one you can change in the project properties to say which framework to build against. The article says that RequiredTargetFramework is used to batch items (but it's still not clear on it' real purpose other than it's not used a lot)
batches the Reference items by their RequiredTargetFramework metadata. The output of the target looks like this:
Reference: 3.5;3.5
Reference: 4.0
Target batching is seldom used in real builds. Task batching is more common. For more information, see MSBuild Batching.
Related
In the WinPhone project of a VS 2015 v2 cross platform solution with Xamarin.Forms v2.2.0.13, two versions of ExceptionStringTable.resx are generated in the 'System Xaml/en-US' and the 'WindowsBase/en-US' folders with different contents. At the moment a dependent assembly, XCRRequiresAttribNotFound, found in both files, has conflicting values during build, one having an extra 'a' in the string. Since they are Build generated, why are they not the same value?
Comparison of Values
It looks like you have Platform specific assemblies referenced in your PCL. In this case, it seems that you have a reference to WindowsBase.dll somehow within your PCL. (This could be inside something like PresentationCore.dll or similar).
I would recommend that you do the following:
Compare this against a File -> New Forms Project (PCL) - To see what default references are within Forms by default in the PCL.
Replace any old desktop/platform specific code with the Forms APIs instead - https://developer.xamarin.com/api/root/Xamarin.Forms/
Profit!
If you have any further problems, I would recommend using grep on certain strings like WindowsBase to see exactly where this is coming from. In this case it's a reference to PresentationCore.dll
I am writing a Visual Studio 2010 property sheet to integrate a complex 3rd party C++ library.
To determine what pieces of the library I need to link to my projects (as well as configuring various defines, includes, directories, etc.), my property sheet needs to determine the project's currently configured C runtime library (i.e. "MultiThreaded", "MultiThreadedDebug", "MultiThreadedDLL", or "MultiThreadedDebugDLL").
However, as a substantially similar question here on stackoverflow pointed out, this MSBuild conditional does not work:
Condition = " '$(RuntimeLibrary)' == 'MultiThreadedDLL' "
Another option was provided, but it was for a subsequent build task. I need this value before ever getting to the build.
I've also scoured Google and Microsoft's MSDN website looking for a way to get this value and have come up empty. Any ideas?
Since there was no way via MSBuild's XML to directly get the configured runtime library, I regex'ed the project file. Here is the XML PropertyGroup snippet to do this:
<PropertyGroup Label="UserMacros">
<RuntimeLibraryRegex>
<![CDATA[<ItemDefinitionGroup Condition=".*']]>$(Configuration)\|$(Platform)<![CDATA['">(?:.*\n)*?.*<RuntimeLibrary>(.*)</RuntimeLibrary>(?:.*\n)*?.*</ItemDefinitionGroup>]]>
</RuntimeLibraryRegex>
<RuntimeLibrary>
$([System.Text.RegularExpressions.Regex]::Match($([System.IO.File]::ReadAllText($(MSBuildProjectFullPath))), $(RuntimeLibraryRegex)).Result('$1'))
</RuntimeLibrary>
</PropertyGroup>
Now the Condition statement in the question will work as-is.
Also, please note that this MSBuild property group XML does not take into account runtime library default (e.g. if the project doesn't have the runtime library set) but can be made to easily.
Our project uses several NuGet packages, a few of which reference LinqBridge, a library that re-implements LINQ to Objects for C# 2.0. The LinqBridge.dll file lives under /packages/PackageName/lib/20/LinqBridge.dll, so it clearly is supposed to only apply to .NET 2.0.
The problem is that, even though every project in the solution is configured to build to .NET 4.0, the LinqBridge.dll binary gets copied over to the final /bin directory and wreaks havoc in Razor views. If I perform .Select() on an IEnumerable, there is an ambiguous call between the built-in LINQ call and the re-implemented one that LinqBridge provides.
I clearly do not need the re-implemented version; if I simply delete LinqBridge.dll from the output /bin directory, everything works just fine. However, that is not an acceptable permanent solution.
Is there any way I can configure something to quit copying that file, which is for an old .NET version, into the /bin output?
Edit: I duct-taped together a solution by adding this to the "Post-build event command line:" commands under "Build Events" in my solution properties:
del $(SolutionDir)\bin\LinqBridge.dll
It's still far from ideal, but at least it lets my project run for now.
NuGet has support for different binaries for different .NET versions so I would suggest that the packages you are using are built badly.
I would contact the authors of the packages and see if they can fix them so that only the net11 or net20 versions include LinqBridge.
Supporting Multiple .NET Framework Versions and Profiles
Many libraries target a specific version of the .NET Framework. For example, you might have one version of your library that's specific to Silverlight, and another version of the same library that takes advantage of .NET Framework 4 features. You do not need to create separate packages for each of these versions. NuGet supports putting multiple versions of the same library in a single package keeping them in separate folders within the package.
(more...)
A useful approach we found was using the LinqBridge.Embedded Nuget package instead of the standard LinqBridge package. This embeds Linqbridge as a C# file within your project, and hence does not get copied over to the bin folder and loaded into the context of the Razor view.
This was useful to us because an assembly we reference still needs to be built in .Net 2.0, as it is also referenced by a 2.0 application. Hence that assembly uses LinqBridge.Embedded, and the LinqBridge assembly does not end up in our 4.0 servers' bin folders.
I know there are other questions regarding this subject, and I've looked at this question, but I'd like to see a little bit more discussion and information on both sides of this - is it a better practice to add a project to a solution and reference the project, or to add a reference to the .dll?
It's not much of a choice. If you have a solution with both projects then use a project reference. If your solution doesn't have the project then you have to use an assembly reference.
So the real question should probably be: do I create a solution with both projects? Yes, as long as the project is still in the debug stage and liable to require bug fixes.
If you only have the dll then you're stuck with a dll reference (obviously).
If you have the source then it's usually better to use a project reference. There might be cases where you have a utility library that's never going to change, but if there's the slightest chance of you needing a bug fix then having a project reference is going to make debugging a lot easier.
Summary - Project Reference by Project vs by DLL
Reference by project
code is visible
finds all references e.g. on a class (because code is visible)
better for testing (over all)
better for code redesign (impact)
Reference by DLL
code is hidden
separation between e.g. framework and project (for deliver of framework)
quicker compilation (because DLL is already compiled)
Well, project references are helpful when you are building and testing in both debug and release mode. If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision.
Relative to your project architecture, you should always stick to projects within your problem domain. You should be using the GAC, if that is applicable to your environment.
I'm getting used to the new IDE (it's vc# express), but the first contact is somewhat confusing. When I open the Add Reference dialog and switch to the .NET tab, a label above the assembly list states: "Filtered to:.NET Framework 4". And it's true - I can reference .NET 4.0 assemblies only plus things like XNA 3.1. However I can't see older assemblies i.e. Managed DirectX libs, which are obviously installed on my computer as there was no trouble with adding a ref to them in vc#08.
What is this? How to change the filter? The label is read-only. These sound like dull guy's questions, but I'm out of luck in finding an answer and there is no intuitive solution.
Thanks in advance.
Change your new application to target the .NET Framework 4 and not .NET Framework 4 Client
"When you create a new application, some projects target the .NET Framework 4 Client Profile by default."
http://msdn.microsoft.com/en-us/library/cc656912.aspx
"If you are targeting the .NET Framework 4 Client Profile, you cannot reference an assembly that is not in the .NET Framework 4 Client Profile. Instead you must target the .NET Framework 4. "
We've created a tool that will help you to achieve your goal. Muse VSReferences will allow you to add a Global Assembly Cache reference to the project from Add GAC Reference menu item.
Regards
s
How to change the filter?
Very simple - you must change the Target .NET Framework for your project, as whole. It's not pain :) just RMB on project name in Solution Explorer->Properties->Application tab->Target Framework(combobox). Select what you want. Change combobox == change filter in Add Reference dialog. ;)
I was having a similar problem until I noticed that the older .NET assemblies were actually in the list, there's just some really strange sorting going on. If you sort by assembly name, you should see them in the proper order.
Another possibility is to go into your project’s Properties page and change the Target Framework from 4.0 to your desired Framework. You will then need to reload you application. Now your Reference should be there. Once you have added the Reference you want, change back to 4.0 and again reload.
Hope this helps.
If, for instance, your project is Framework 4 and you want to reference say Microsoft.Deployment.WindowsInstaller (which is not in the filtered list of the .NET tab), then go to the Browse tab and enter the path to the reference item e.g. C:\Program Files\Windows Installer XML v3.5\SDK\Microsoft.Deployment.WindowsInstaller.dll