I am working on a project that requires me to build a .dll file in .NET framework 4.x
I know this would be super easy if I were to use Visial Studio. But I have set my mind on using VS Code as my IDE.
In theory Visual Studio "only" automates the creation of all sorts of metadata and references. So I figured it should be possible to do these things manually. Correct?
Can anybody direct me to where I can find how to do that?
I am working on Windows 10.
Because Code isn't adept at managing a project file (.csproj) - nor should anyone have to - you can actually use the dotnet.exe CLI to create the project and target .NET Framework instead. The only requirement is that .NET Core SDK needs to be installed, even if you use MSBuild because the new SDK-style project requires different targets.
Run: dotnet new classlib -o MyLibrary
Run: code MyLibrary
Open MyLibrary.csproj in Code
Change the line <TargetFramework>v4.5</TargetFramework>
Now you can run dotnet build or msbuild build, and even set up build and test tasks in Code. By default, Ctrl+Alt+B will run a build task, or prompt to create one from a template if none exist yet.
Now you can simply add files without modifying the .csproj file. I participate in many OSS projects that use technique and can easily switch between VS, Code, or even non-IDEs like vim.
It would require from you to type a lot of code and files that are otherwise automatically scaffold (generated) when you create a new project in Visual Studio. Even though VS Code is supportive for .NET framework coding (with the C# plugin), I would advice you to use Visual Studio (the community version would suffice). It has much better support for any .NET framework development.
Related
I recently moved my winform project from .NetFramework to .NetCore3.0.
My earlier project had WiX installer support for building a nice and clean installer. But, now i don't see any such support for .NetCore3.0. Also, WiX installer project is no more compatible in VS2019. Do you have any suggestions?
WiX has an extension for VS2019. (I contributed it.)
When you create a WiX setup project in VS it asks you what version of .NET to use. This question isn't actually relevant and has no effect on the project generated. It's just part of the VS2019 project template system and isn't hidden.
I have an FOSS solution called IsWiX that makes creating this type of installer super easy. You can see how it works by looking at the desktop tutorial found at:
https://www.github.com/iswix-llc/iswix-tutorials
The only real difference between .NET Framework and .NET Core is you have a lot more choices in how to build your project. This means you might no longer author an AppSearch/LaunchCondition and/or create a bootstrapper to install .NET Framework. You might instead deploy a private copy of the framework with your application or you might create a single self contained executable. You have more choices here. But WiX, IsWiX and MSI still all work great here.
I'm not even sure if what I'm trying to do is possible...
Sample code: here
Basically, I've built a netstandard20 class library which according to the .NET implementation support list should be compatible with a framework461 project (providing you have the .NET Core 2.0 SDK).
I can build the netstandard20 class library no worries and get the DLL back (it's included in the sample code).
This is where the problem starts, when attempting to run msbuild .\netstandard_test.sln to build the framework461 project I get a whole bunch of (what I believe to be misleading) errors about 'netstandard' not being referenced (which it is).
However, if I run dotnet build (or build from VS2017) everything works as expected.
I've tried importing various versions of NetStandard, NetStandard.Library and NetStandard.Library.Framework, as well as referencing Microsoft.DotNet.BuildTools but that didn't appear to help.
Is there any way to build this using msbuild? We have a monolithic build and deployment process and I'd rather not have to change it if it can be avoided. Who knows what else would go wrong!
To build with .NET Core or .NET Standard you need to use the dotnet msbuild command from the .NET Core SDK rather than just plain msbuild.
dotnet msbuild .\netstandard_test.sln /p:Configuration=Release
This will also work with .NET Framework 4.6.1 (and older versions).
Do note that Microsoft has provided install scripts to make installing the .NET Core SDK painless on continuous integration servers.
You need to use a recent 15.* version (currently 15.5.*) of MSBuild and make sure that the "Cross platform development" workload is installed in visual studio. This adds the required components to locate the .NET Core SDK, which contains MSBuild SDKs like Microsoft.NET.Sdk or Microsoft.NET.Sdk.Web used by .NET Standard and .NET Core projects.
You can then use msbuild from the developer command prompt to build these projects. I suggest adding /restore (msbuild >= 15.5.*) to make sure that a NuGet restore happened for sdk-based projects.
Since VS 2017 does not install a "global" version of MSBuild, be sure to use the version of MSBuild installed in the VS 2017 folders (check with msbuild /version or where msbuild).
dotnet msbuild has limitations when you use .resx files containing file references or non-string properties. Also, it does not support COM references or building strong named assemblies. If you need any of these features, use msbuild (VS 2017) over dotnet msbuild (.NET Core CLI)
I'm trying to build my C# (WPF) project, which I originally generated in Visual Studio 2017 in VSCode. If I open a command prompt and build the project with C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe .\[Name]\[Name].csproj /t:Rebuild /p:Configuration=Debug
the build succeeds and the program runs as expected, but with the following message (not a warning nor an error):
Project file contains ToolsVersion="15.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="4.0".
But when I try to run and build in VSCode (Start with Debugging (F5)), the build fails. Also, VSCode shows every XAML-Element I referenced in code as undefined:
(The name '[Button/Label/TextBox/etc.]' does not exist in the current context [Name]
What do I need to define in the tasks.json and launch.json to make VSCode build my project?
The C# support in VS Code is optimized for cross-platform .NET Core development. WPF is neither cross-platform nor .NET Core and VS Code does not support debugging WPF applications. Due to this focus, many of the standard C# project types are not recognized by VS Code: https://code.visualstudio.com/docs/languages/csharp.
If you want the best possible experience when creating WPF applications, you should use Visual Studio.
I don't think that VSCode supports WPF since it focusses on projects built with .NET Core and Mono. WPF is not supported in .NET Core
I am referencing Gtk# and building using Mono, writing my code in VS Code (code.visualstudio.com). I'd like intellisense for C#. By "intellisense" I mean the correct functions, members, etc. come up with "." - this is separate from predictive suggestions based on other code in the file.
I have tried both the current Microsoft C# extension (https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp) as well as the Legacy Microsoft C# extension (https://marketplace.visualstudio.com/items?itemName=ms-vscode.omnisharp).
Both of these appear to use OmniSharp as the means for providing intellisense, and both either load MS Build files and/or "project.json" files.
The current Microsoft C# extension seems to use "project.json" files which appear to follow a schema specifically for .NET Core. I tried to leverage this anyway by creating a local GtkSharp NuGet package out of the Mono DLLs, but I could not then "dotnet restore" because these NuGet packages were incompatible with .NET Core. I followed: https://docs.nuget.org/ndocs/hosting-packages/local-feeds and https://docs.nuget.org/ndocs/create-packages/creating-a-package
The Legacy Microsoft C# extension works if I use Visual Studio to generate solution (.sln) and project (.csproj) files. VS Code then recognizes these files and uses intellisense properly. Trying to hand-roll solution and project files failed because there seem to be a lot of entries OmniSharp is looking for when setting up using this method.
Fundamentally, I want to provide a simple lightweight configuration which says: "Here is my code (.cs files), and here are the assemblies I reference (.dlls) as well as their comment files (.xml)" - and then have VS Code provide intellisense for those files and referenced assemblies. The .NET Core "project.json" files are simple enough, but are incompatible. The MS Build files are significantly more complicated than what I am looking for and require Visual Studio (or maybe a much deeper knowledge of MS Build) to generate OmniSharp compatible files. I'm looking for a separation between build configuration and intellisense configuration.
How can I configure VS code to support intellisense for C# without the use of .NET Core or MSBuild?
This has nothing to do with build systems, and strictly relates to providing intellisense support using one of the OmniSharp-based C# VS Code extensions provided by Microsoft without the use of "project.json" or MS Build configuration files.
I read the following both articticles about the using of portable class library(PCL) in application design:
http://www.dotnetcurry.com/showarticle.aspx?ID=843
and
http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx
I created an PCL and a unit test project to test the PCL. I build everything with my visual studio 2012 and it works great, i was also able to start my application using this PCL.
I use a TFS for source controll and nightly tests.
If i try to build the the unit test project or my apllication via TFS i retrieve two errors:
CA0055 : * Could not load file: 'C:...\MyPCL.dll'.
CA0052 : No targets were selected.
The PCL use .Net Framework 4.5 and .Net for Windows Store apps as targets and all projects which are no PCL are configured to use .Net Framework 4.5. I does not use any other reference as the default ".Net Protable Subset" reference.
If i check the build server there is a compiled and working version of my PCL.
If i disable the code analysis while building there are no errors and all unit test works fine.
But it is no solution for me to disbale the code analysis. So has anybody an idea why it crashed and how to get it working with code analyse?
I ran into the same problem after renaming the project. Check the AssemblyInfo.cs file, make sure the assemblyTitle is correct. Better to have it same as the project name, and is not conflicting with any other projects
Is your local build working fine when code analysis is enabled in Visual Studio?
If yes then one of the possible reason for this issue can be build output path in TFS Build. In local builds, output files are generated in bin directory of respective projects where as in TFS Build all the project output files are copied in binaries directory.