How to configure automatic builds on Azure to use c#6 compiler - c#-6.0

I'm ready to publish a MVC5 application using C#6 compiler to azure.
My automatic builds return errors about not understanding nameof, etc.
Is there anyway to change some configuration so my builds and application uses C#6 compiler ?

I finally installed the nuget package called Microsoft.Net.Installer (1.0.0-beta2).
This worked like a charm and I don't know if there's another way to do it, but since I only have 1 project this wasn't a problem.

Related

Conditional Compilation Symbols not working

There are plenty of reported bugs in almost every version of Visual Studio with similar or exactly the same issue. The problem is that every bug report I found has been already resolved. Additional info: My exact same code has worked a month ago. I am using .NET Core 3.1.100 and Visual Studio 16.4.2.
Project GUI
.csproj Configuration
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Demo|AnyCPU'">
<DefineConstants>DEMO</DefineConstants>
</PropertyGroup>
Code (as you can see, the DEMO symbol will not be applied).
Has anyone an idea how to hotfix this issue for my production environment?
Thanks in advance!
This is not how this should be done in ASP.NET Core. ASP.NET Core doesn't use the concept of build configurations natively, and while you can sort of use them in places like this or compiler directives, it goes against the grain of ASP.NET Core app design. ASP.NET Core apps are build once, deploy anywhere, in contrast to ASP.NET where you needed to build for each environment separately.
Instead, this should be handled via config and environments. You can even have a "Demo" environment, if you like, which would then allow you to just inject IWebHostingEnvironment and check _env.IsEnvironment("Demo"). Short of that, you should simply specify via config (JSON, environment variable, etc.) a "Demo" boolean, and then pull that out of IConfiguration.

What is the .exe file that VS generates via .NET Core self-contained deployment?

[I'm using Windows conventions for convenience but this is an x-platform question.]
When I publish a .NET Core project (named, say, Tannery) via SCD, Visual Studio generates the application file publish\Tannery.exe, which is my entry point into publish\Tannery.dll. In addition, from what I've tested, publish\Tannery.exe automagically works with any config/build of Tannery.dll [on the target runtime].
This suggests Tannery.exe is just a thin wrapper around dotnet.exe and tantamount to dotnet Tannery.dll. However, I can't find documentation on this. So, what "is" this application file, and how flexibly can one use it?
When you use SCD you build your project for a specific runtime (e.g. windows x64), the build would include all the dotnet dependencies, so when you run your SCD on a system without the dotnet SDK, it will run without problem.
You can think about it as a wrapper around dotnet.exe, where the dotnet.exe is part of the build and not a system dependency.

An exception occurred while invoking executor 'executor://mstestadapter/v1': Object reference not set to an instance of an object

We are using Visual Studio 2012 and Team Foundation Server 2010 in our project. Since, we are using Microsoft Fakes, we could have not used the started Test functionality of our Team Build 2010, I have created a build activity which invokes VSTest.Console.exe passing the test assemblies. This approach has been working well for us. However, after a recent check-in we are getting the following error when executing Vstest.console.exe
Error: An exception occurred while invoking executor 'executor://mstestadapter/v1': Object reference not set to an instance of an object.
I copied the binary files to my local machine and was able to get the error again. Interestingly, we run a dev build before check-in which runs the same vstest.console.exe with the same parameters and that works correctly. I have got two folders on my machine, for one the call works fine and for other it doesn't. The compiled assemblies look same size and there aren't much differences to suggest.
I tried using Process Monitor but couldn't find anything obvious other than that the process returns with an exit code 1. Does anybody know much about this error? Is there any way I can find out more information from my test run?
Regards,
Hamid
We got to the bottom of the problem. We are using Entity Framework 5.0 and we also have a situation where some of our test assemblies are targeting .Net 4.0 and some are targeting .Net 4.5.
When we are trying to run the tests such that assemblies targeting different versions of .Net framework and using Entity Framework 5.0 are run in the same Test (vstest.console.exe) process, we get this error.
I think this has to do with the way Entity Framework 5.0 ships with two versions (net40 and net45). Once one version of the library is loaded in the process, the other version cannot be loaded and this caused the error.
I had the same error message just now with Visual Studio 2017 using the new MSTest.Framework and MSTest.TestAdapter (to be able to use Live Unit Testing). It turned out I was using multiple versions of those packages in my solution. Consolidating them to the latest version solved the problem.
This is what worked for me:
In Visual Studio, Test -> Test Settings -> Default Processor Architecture -> X64.
Though it might not solve everyone's issue, hope it helps some of you out there.
I have the same error specified in the subject when in the AssemblyInfo of the project is specified the AssemblyAttribute:
[assembly: AssemblyCulture("en")]
If this attribute is present, the run of the unit tests fails.
If I remove this line of code or I remove the en language, the run of the unit tests success.
An exception occurred while invoking executor 'executor://mstestadapter/v2'
I had multiple TestAdapter's and TestFramework's in my BuildAgents Folder, deleting the v1.1.11 versions fixed the issue:
This happened to me recently in VS 2019. Using NuGet to update to the latest versions of MSTest.TestAdapter and MSTest.TestFramework solved the problem for me.
I tried everything on the web to solve this exception. Finally I solved this issue by installing the Update v4 of Visual Studio 2013 (which is that I'm using currently). Hope it helps!
Deleting app.config and packages.config, if exists, and reinstalling Entity framework via nuGet packages works for me.

visual studio 2010 release can't find dll

I've build a project with opencv, when I share my .exe on other pc they can't find some dlls, this happens in release and debug mode, I searched on the web and I know I must configure the properties of the project, I tried configure MFC but with all the configuration the problem persist.
thank you!
Are they SystemFramework libraries? Or are they libraries that your app specifically uses, ones that you have imported into the project?
If they are your custom/imported libraries, make sure you copy them to output, and send them with the exe. The point of an installer is to bring the client your executable will of the the files it need to reference, compiled into a single file.
It seems the runtime librarie of opencv are missing. I'm not familiar with opencv, but VS provides a way to find all dependencies: http://msdn.microsoft.com/en-us/library/vstudio/dd293568.aspx. You can build an installation package for your application.
Another way to find all dependencies is using depends.exe, details are in:http://msdn.microsoft.com/en-us/library/ms235265.aspx

Oracle.dataaccess dependencies on tfs build controller

How to solve issues of installed stuff that my solution depends on?
I have a problem with oracle data access in my build controller: it says that it can't load Oracle.DataAccess or one of its dependencies.
So should I install ODAC on the build controller machine or copy dlls from program files ? Or anything else?
The problem exists only for the asp.net web site project, this project got no code, just global.asax and dependencies for other projects in solution, if I remove it from the build it's all works fine.
I would recommend installing the dlls as normal. This way if you do any unit testing or whatnot all will work out-of-the-box.
--That would be the main argument for having it installed.
Otherwise, you will reduce Build controller maintenance and such if you copy over the dlls.
It's pretty much a similar argument that they detail here (sans licensing cost which don't exists for ODAC)
http://msdn.microsoft.com/en-us/library/ff622991.aspx

Resources