I've noticed that release exes for VS 2017 C# projects built with msbuild are about 30% larger than previous builds for VS 2015 (the source code is identical for both cases).
Is this normal or is there some new switch in project properties that I'm missing?
Related
I want to deploy a C++/CLI application on Windows 7 32bit clients. I have built it using Visual Studio 2017 and I noticed my project needs Visual C++ 2017 Redistributable.
My executable file is less than 1 megabytes and the MSVCR dependency is 13 megabytes, which is really huge for this app.
Is there any way I can reduce this amount of size?
I found a possible solution but I don't know if it is fine or not.
I can compile my C++/CLI code with Visual Studio 2010 toolkit. So I would need C++ Redistributable 2010 for it.
And instead of installing the whole package I can copy msvcr80.dll and msvcp80.dll next to my executable file, which are less than 1 megabyte size together.
When I publish .net core application in Visual Studio 2017 RC, it creates 2 unwanted dll's, which are as follows:
Microsoft.DiaSymReader.Native.amd64.dll
Microsoft.DiaSymReader.Native.x86.dll
It happens only in Visual Studio 2017 RC and not in Visual Studio Express 2015.
I have found following link on github, but fix mentioned over there only removes ref folder from publish output.
https://github.com/aspnet/websdk/issues/123
Is there any way, by which I can get rid of these 2 heavy dll's as they size around 2MB in total?
This was caused by a bug in Microsoft.NETCore.App version=1.1.0. When you reference that version, implicitly (the default), or explicitly, you will get those two assemblies in your publish directory.
The fix is to either upgrade to Visual Studio 2017 RTM, which implicitly references the version with the fix (1.1.1), or to explicitly reference 1.1.1 by adding <RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion> to your .csproj.
I'm currently working on a Visual Basic project with a team of developers, some of which will be able to move to Visual Studio 2015 as soon as it is released, and some who will be stuck on Visual Studio 2013 for several months. In testing with the RC we have found that Visual Studio will open 2013 projects without a problem, but will happily let users use new language features, such as string interpolation, that are not available for users in VS 2013. If a 2015 user checks in this code the 2013 users will get compile errors. Is there any project, solution, or Visual Studio setting that will tell the compiler to restrict features to what is available in the previous version of VB.net? Ideally the compiler should return a compile error when trying to use these features in 2015.
This features is available in C# under Project Properties > Build > Language Version, but I can't find any equivalent for VB.net, and the google searches are failing me.
I just wanted to mention that setting the .Net runtime version to 4.5 doesn't help, as these new language features are compiler level features that work perfectly fine on older frameworks.
There is no UI feature to set the Language version, but you can unload the project file and add <LangVersion>11</LangVersion> to default Visual Basic to the 2012/2013 language settings. The C# project adds this property under the Project Configuration property groups, so for consistency's sake I've done the same in the sample below.
The C# property pages do the same thing, except that C# uses a different set of version numbers.
A full set of all the language versions can be found here.
2002 (VB 7.0)
2003 (VB 7.1)
2005 (VB 8.0)
2008 (VB 9.0)
2010 (VB 10.0)
2012 (VB 11.0)
2015 (VB 14)
Just tested and this works for me, but I did have to change the casing to:
This results in:
And a nice build failure:
I've written a c# program that builds *.csproj and *.vcxproj using Microsoft.Build.Evaluation. It works great on both project types if I compile and run it from inside Visual Studio 12. But if I run the exe directly (outside of Visual Studio) I get the example error message below. The error occurs only for vcx projects; c# projects continue to build just fine
Question: Why am I getting this error? Why does my program work fine for both C# and vcx projects when run from within VS12, but fails, but only for vcx projects, when run outside of VS12?
Please don't chastise me for not using MSBuild.exe. My orders were to programmatically build C# and vcx projects using Microsoft.Build.Evaluation.
Code:
using Microsoft.Build.Evaluation;
...
Project proj = new Project("MyCppProject.vcxproj");
proj.Build(logger);
Runtime Error:
Building MyCppProject
Project "MyCppProject.vcxproj" (default targets):
VCMessage:
ERROR C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
Done building project "MyCppProject" -- FAILED.
One solution is to force the Visual Studio version as an environment variable prior to loading and building the project:
using Microsoft.Build.Evaluation;
...
Environment.SetEnvironmentVariable("VisualStudioVersion", "11.0")
Project proj = new Project("MyCppProject.vcxproj");
proj.Build(logger);
Visual studio maintains platform tool sets list supported for the version of Visual studio you are currently running for example on my machine I have VS 2008, 2010 and 2012
Now suppose when I install Visual Studio 2013 which has a Platform Toolset version of V120. What happens, is that the project saves this in its corresponding XML files in the format (vcproj, vcxproj, vcxproj.filter.user files).
now this valus is not known to VS 2012 so it complains when opened in VS 2012.
Similarly for opening VS 2012 project in VS 2010, as in your case and so on.
Solution:
To fix this issue, Open you solution file in notepad++.
Make these 2 changes
1) Replace
Format Version 12.00
with
Format Version 11.00
2) Replace
Visual Studio 2012
with
Visual Studio 2010
Then open the file again in visual studio and rebuild solution.
I have written dozens of custom code analysis rules. The rules were developed targeting Visual Studio 2010. As required, the assembly has a reference to version 10.0 of FxCopSdk, Microsoft.Cci, and Microsoft.VisualStudio.CodeAnalysis. They run correctly in Visual Studio 2010 and build properly in TFS 2010.
I'd like to migrate to Visual Studio 2012. When I run the custom rules on an existing solution using VS 2012, however, I get CA0062 errors. The root cause is a CA0053 error loading the custom rules assembly. I understand that these references to the three assemblies need to be updated to version 11 for Visual Studio 2012. This can be done using version redirects in config files. I can get this to work locally by redirecting the Visual Studio 2012 IDE and FxCopCmd binaries, but am running into trouble when checking code into TFS 2010.
There are two apparent solutions we have considered, but neither is very palatable. The first is to require each developer to redirect locally, and then modify the TFS build agents to redirect as well. The second is to maintain two branches of the custom code analysis rules, one targeting version 10 (VS2010) and the other targeting version 11 (VS2012).
Is there a better way to do this, or do we need to all upgrade to TFS 2012 and Visual Studio 2012 simultaneously?
You can try to manually edit the project file and write two include blocks (one for VS2010 and one for VS2012), then define conditions to use the correct one. You only have to somehow determine if You want to build for VS2010 or VS2012 in msbuild.
Between your approaches and the one proposed by ZFE, you pretty much have all the potential candidates. Given the choices, I would strongly recommend branching since there is no official SDK for FxCop with backward-compatibility guarantees.
If you're lucky, you won't hit any behavioural or API surface changes that affect your rules, and the only difference between your two branches will be the references, so any merges will be trivial. However, any time investment you make in an alternate approach now will be lost if you need to branch later, and the likelihood of eventually needing to branch is non-negligeable.