The following code can be compiled and run, without having an explicit reference to a Microsoft.VisualBasic dll or package:
using Microsoft.VisualBasic;
Interaction.Beep(); // from Microsoft.VisualBasic
System.Console.WriteLine("Done");
Here the corresponding project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
</Project>
Look under Dependencies > Frameworks in the Solution Explorer and you'll see Microsoft.NETCore.App listed. Expand that node and you'll see all the assemblies included in that framework, which includes Microsoft.CSharp, Microsoft.VisualBasic and Microsoft.VisualBasic.Core. That means that VB projects have a reference to Microsoft.CSharp as well.
Related
I have an "old style" .NET framework project which includes nuget references and other project references. Now I switched to the PackageReference format (removed the packages.config). I want to create a NuGet package for my project. So I added a reference to the "NuGet.Build.Tasks.Pack" package and used the MSBUILD pack target. In the first place it looked everything as expected, the resulting package contains all my references and the corresponding NuGet references. Now I have the problem, that I use also a project to project reference:
<ProjectReference Include="..\Wrapper\MyWrapper\MyWrapper.csproj">
<Project>{6b9a7dd0-b93f-3a5e-8fdf-99d0bf811652}</Project>
<Name>MyWrapper</Name>
</ProjectReference>
Based on the nuget documentation - for this reference:
Project to project references are considered by default as nuget
package references
But I want that this project reference is packaged into my package instead of a "nuget package reference". I found postings that using
PrivateAssets="all"
for the project reference could fix the problem, but adding this attribute to the project reference node does not change anything. Any help would be great!
I think you have missed something. It is not enough that you set PrivateAssets="all" for the ProjectReference. And actually, nuget will not view the referenced project as a nuget dependency and also nuget will not pack its assembly dll into the nupkg. You need other nodes.
Try these guidances:
Assume all your lib projects are target to net framework 4.7.2.
1) add the PrivateAssets="all" on the xxx.csproj file of the main project.
<ProjectReference Include="..\Wrapper\MyWrapper\MyWrapper.csproj">
<Project>{6b9a7dd0-b93f-3a5e-8fdf-99d0bf811652}</Project>
<Name>MyWrapper</Name>
<PrivateAssets>All</PrivateAssets>
</ProjectReference>
2) also add these node on the xxx.csproj file of the main project to pack the assembly dll into the nupkg:
<PropertyGroup>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<Target Name="CopyProjectReferencesToPackage" DependsOnTargets="ResolveReferences">
<ItemGroup>
<BuildOutputInPackage Include="#(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))" />
</ItemGroup>
</Target>
3) then use this command to pack the project:
msbuild -t:rebuild,pack -p:PackageOutputPath=xxx\xxx -p:Authors="xxx" -p:Version="x.x.x"
Note: In my side, the main project called Mod and it references a project called Mod1. When I finish the pack process, you can see these in the nupkg.
It packs the refeneced dll as a lib rather than a nuget package.
I want to add a package to my project, but it says:
error: Package PixivCS 0.4.4 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package PixivCS 0.4.4 supports: netcore50 (.NETCore,Version=v5.0)
Then I tried to change the target framework using the properties option in VisualStudio, but the .NET 5.0 is the only option
screenshot
If change the <TargetFramework>net5.0</TargetFramework> in .csproj to <TargetFramework>netcore50</TargetFramework>
Error NETSDK1013 The TargetFramework value 'netcore50' was not recognized. It may be misspelled. If not, then the TargetFrameworkIdentifier and/or TargetFrameworkVersion properties must be specified explicitly. HelloWorld C:\Program Files\dotnet\sdk\5.0.100-preview.3.20216.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets 100
How can I change the framework of my project form net5.0 to netcore50 so I can use that package?
What's the difference between .NETCore and .NETCoreApp?
Update with new version. Please go here https://visualstudio.microsoft.com/downloads/ and update your VS. Then try to replace:
<TargetFramework>net5.0</TargetFramework>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
</Project>
In my solution I have a project "commons" and project has reference like SpecFlow.CustomPlugin. When I build the project Com.Org.Commons.dll will get generated.
But when I refer this .dll file to another project (please look into attached image solution structure
)
"SFP" which has class NUnitPropertyGenerator.cs also need reference of SpecFlow.CustomPlugin which is already included in commons project.
I build the project commons and Com.Org.Commons.dll will get generated. But when I include the Com.Org.Commons.dll into SFP project below code gives me error and it doesn't refer to Com.Org.Commons.dll.
using TechTalk.SpecFlow.Generator.Plugins;
using TechTalk.SpecFlow.Generator.UnitTestProvider;
using TechTalk.SpecFlow.Infrastructure;
[assembly: GeneratorPlugin(typeof(Com.Org.SFP.CustomNUnitProperties.SpecFlow.NUnitPropertyGenerator))]
namespace Com.Org.SFP.CustomNUnitProperties.SpecFlow
{
public class NUnitPropertyGenerator : IGeneratorPlugin
{
public void Initialize(GeneratorPluginEvents generatorPluginEvents, GeneratorPluginParameters generatorPluginParameters)
{
generatorPluginEvents.CustomizeDependencies += (sender, args) =>
{
args.ObjectContainer.RegisterTypeAs<MasterProvider, IUnitTestGeneratorProvider>();
};
}
}
}
I thought TechTalk.SpecFlow will get refered if I include Com.Org.Commons.dll in SFP project which internally referes SpecFlow.CustomPlugin package.
Expected result should be:
SFP project should successfully build after including the Com.Org.Commons.dll and should resolve the code error which are related to TechTalk.SpecFlow. Logically both the project required SpecFlow.CustomPlugin package but as I am seperated out the details implementation to commons project and considering common project has a reference package included in dependencies I should be able to resolve the error in SFP project after referencing the Com.Org.Commons.dll in SFP project.
Please find .csproj file content
commons.csproj (https://gist.github.com/gittadesushil/100df50d4de72d61a9d57aa08c82cada)
SFP.csproj (https://gist.github.com/gittadesushil/dda1af31b5351f6ef9c71e44e2ceccda)
If you need to use the namespaces/classes defined in SpecFlow.CustomPlugin DLL, you will need to add a reference to that DLL directly in all projects where you are using its classes directly in code. For e.g., TechTalk.SpecFlow.Infrastructure looks like a namespace from SpecFlow.CustomPlugin that's being used in SFP. In this case SFP needs to have a reference to SpecFlow.CustomPlugin
If you were not using TechTalk.SpecFlow.Infrastructure directly in SFP then all you would need to do was to ensure that the CopyLocal property of the SpecFlow.CustomPlugins reference in commons was set to true.
You are using a normal Reference (https://gist.github.com/gittadesushil/dda1af31b5351f6ef9c71e44e2ceccda#file-sfp-csproj-L25) and not a ProjectReference.
correct would be
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net45</TargetFramework>
<RootNamespace>Com.Org.SFP.CustomNUnitProperties.SpecFlow</RootNamespace>
<AssemblyName>Com.Org.SFP.CustomNUnitProperties.SpecFlow.2.4.SpecFlowPlugin</AssemblyName>
<PackageId>$(AssemblyName)</PackageId>
<Description>$(PackageId)</Description>
<OutputPath>$(SolutionDir)Output\</OutputPath>
<DocumentationFile></DocumentationFile>
<IsTool>true</IsTool>
<BuildOutputTargetFolder>tools\SpecFlowPlugin.2-4</BuildOutputTargetFolder>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
<GenerateSerializationAssemblies>Auto</GenerateSerializationAssemblies>
<WarningLevel>0</WarningLevel>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="Com.Org.Commons" />
</ItemGroup>
</Project>
Normal References don't look at the dependency graph.
I'm working on a class library that I've multi-targetted to both net461 and netstandard2.0
One of the dependencies of this class library is Microsoft.ApplicationInsights
When it was targeting just net461, I could add a reference to Microsoft.ApplicationInsights (v2.4.0) via package manager console, or nuget ui, and it would add itself as a dependency.
Once I've multi-targetted the csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net461;netstandard2.0</TargetFrameworks>
</PropertyGroup>
</Project>
... if I try to add a reference, it asks me to accept license agreements for many, many dependencies.
Of course, I duly did so.
My issue comes when I package this class library as a nuget package.
Even if my consuming application targets net461, when I install this package, I am prompted to install all the netstandard dependencies - even if my consuming application doesn't target netstandard.
Is there a way to stop my net461 targetted package requiring all the dependencies for netstandard?
Have you tried using conditions in the project file to make some dependencies target framework specific? I've had similar sounding problems, though not with creating nuget packages, and this helped.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net461;netstandard2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
<Reference Include="DependencyA" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' ">
<PackageReference Include="DependencyB" Version="1.0.0" />
</ItemGroup>
</Project>
Another idea would be to look at existing open source projects out there and see how they're solving it. Though finding one using Microsoft.ApplicationInsights may be trickier.
This is my first time trying anything that targets more than just a .NET Framework. I can't seem to do it from the GUI. I've tried project type 'Class Library (Portable)' and project type 'Class Library (.NET Standard)'. I can change a 'Class Library (Portable)' to target .NET Standard but then I can't select anything else. I'm not sure if I should try to change the .csproj of 'Class Library (.NET Standard)' or the project.json of 'Class Library (Portable)', I just want whatever is most future-proof.
As of a few days ago the .csproj has been simplified and ease of use has improved. With the latest version of VS 2017 RC, I create such a library by creating a new 'Class Library (.NET Standard)', which has this default .csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
</PropertyGroup>
</Project>
And I edit it by hand (I don't see a way to do it through the UI) to be this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.3;net452</TargetFrameworks>
</PropertyGroup>
</Project>
The 'Target framework' drop down under the project's Properties pane then becomes grayed out. By building you can verify separate netstandard1.3 and net452 folders under bin\Debug. Be aware of the following issue if you're creating a NuGet package on build, which may mislead you into thinking you've done something incorrectly: https://github.com/NuGet/Home/issues/4289.