I've read a lot about advantages(speed and flexibility for example) of using .NET Command-line interface so i tried it. I created new ASP.NET Web Api project via PowerShell. It was all good until i wanted to install some Nuget packages. I could not do it in the IDE(VS2019) because the Nuget manager is disabled(package menager console gives me 'No default project). I added Entity Framework package using CLI but first i had to created new solution(using CLI) to the project for some reason. Now to make migration i need to use commands for EF... how is it more flexible than using GUI? It seems for me it's one or another.
My question: how do you guys use CLI? Is there a really good reason to use it?
Is it possible to use CLI along with GUI?
Actually, it can be done and since you want to use CLI to create a project the same as GUI does(have a xxx.sln file). Since dotnet command line is quite simple to create a project but creating it as VS IDE does(xxxx.csproj with SLN files and all levels of projects) requires a further command like these:
1) use cmd to cd a folder called Project and then type this:
dotnet new mvc -o <Solution_Name>/<Project_Name> -n <Project_Name>
Then create a solution folder and the project but it lacks the <Solution_Name>.sln file. And you should use dotnet sln command.
2) create the a file named <Solution_Name>.sln under the Solution folder and add these in that file:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.28701.123
MinimumVisualStudioVersion = 10.0.40219.1
Then CMD:
cd <Solution_Name>
dotnet sln add <Solution_Name>.sln <Project_Name>\<Project_Name>.csproj
3) Then it will created as the GUI does.
Besides, CLI is simple and convenient(apply for a single project) but if should be as GUI does(a solution contains several projects), it needs to do some extra operation like some other commands, by GUI, it will automatically be created without any steps.
In addition, if you want to install a nuget package by CLI, you could use dotnet add package command without install it in GUI, like this:
CMD
dotnet add package Newtonsoft.Json -v 12.0.1
Update 1
In fact, each has its advantages and disadvantages, the score situation to deal with.
To create a single project and do something about the current project，using CLI is more convenient. It takes a lot less of the computer's system resources and it can react quickly and improve performance. However, if it involves multiple complex projects, and strive to operate on multiple projects, because CLI is too direct and not as visual as GUI, easy to operate, it is too complicated to be suitable for novices.
For more comparisons, you can refer to this link for more detailed info.
Related
One of my vcxproj's (with a vcpkg.json) looks like this
And another one (with a vcpkg.json) looks like this. Note the missing option.
But I need to be able to enable the vcpkg Manifest so it can compile! I'm stuck, where did this option go? Both proj's are in the same solution. Both have vcpkg.json added to their Source Files. Notably one has a different dir structure (proj/proj.vcproj vs proj/build/proj.vcproj) so the vcpkg.json is further away
As a design note, conditionally hidden options or grayed-out options are an anti-pattern.
A vcpkg.json alone is not enough. vcpkg needs to be enabled in your proj.vcproj file.
Try the following steps:
Close the solution
Open the proj.vcproj files in a normal editor
Look for the VcpkgEnableManifest and other vcpkg properties in there.
Better still, use WinDiff or a similar DIFF tool to discover the differences between the vcproj files.
I cannot be more specific because you didn't say how you imported/integrated the vcpkg options into your project in the first place. There are many different ways to do that.
For example, I am using the vcpkg export --nuget command to export a nuget package, which I then add to my individual projects with the Visual Studio nuget package manager. This will import "vcpkg.props" from the nuget package directory. This import command adds the options you are missing. If you are using the same method, you probably forgot to add the nuget package to your other project. This way of integrating vcpkg is "per project" rather than globally, so it does not matter if the two projects are in the same solution or not.
If otoh you used the vcpkg integrate command to integrate the vcpkg globally, things will be different. In this case the import command will be inside some Microsoft.props file and the options should appear in all projects.
Okay, I found out how to fix it. I had gotten myself in a corrupted state by unloading and loading VS projects while VS was open AND while running vcpkg integrate project/install commands.
I misunderstood those commands. I thought vcpkg integrate project installed MSBuild vcpkg just for that project so I thought I had to run that for each .vcprojx.
Rather, vcpkg integrate project may be better named vcpkg integrate nuget and vcpkg integrate install could be named vcpkg integrate msbuild?
In any case, the fix was to close all instances of Visual Studio (I even uninstalled extra versions), and just run vcpkg integrate install ONCE and then reopen Visual Studio. Then it worked.
I have a C# dotnet core solution and it contains many projects. Then I want to publish my solution to distribute my build application.
When I run dotnet publish -o publish/win1064 -r win10-x64 in a folder with the sln file (I'm using dotnet core sdk 3.1), all build artifacts (dlls) are stored in the publish/win1064 folder. I want to have some projects to be published in a subfolders, like publish/win1064/plugins/pluginA for a project "pluginA" for example.
I can do it by running the dotnet publish for every project and set the output folder accordingly, but is there any way to do it with a one command?
I'm not aware of a safe way of invoking dotnet publish at solution level, I would strongly advise you not to do it. You can find other answers stating the same out there.
That's why most CI tools allow you to use some kind of wildcards (i.e., **/*.csproj) to run dotnet commands over multiple projects, but not at solution level.
You'd face similar issues if you try to run tests at solution level and collect coverage/test results from that. (i.e. dotnet test /p:CollectCoverage=true /p:CoverletOutput=./CoverageResults).
is it possible to utilize my NSIS installer script to make an automated build (daily) for my program in TFS 2010? The program isnt C#, it's actually small talk, so the installer being designed in NSIS was prior to our group being required to migrate source control into TFS.
Essentially the installer just copy/pastes the directory and shortcuts onto destination PC, and runs a regedit for the new parameters. I noted in the TFS build tool (which I'm extremely unfamiliar with) that it constantly wants me to point at a .proj file.. Does this mean I've got to convert our NSIS scripts into some .NET equivalent (if so how?) or is there a plugin of some sort to allow these guys to play nice together?
If your project support MSBuild to build it, you can use TFS Team Build directly. If your project doesn’t support MSBuild to build it, you need to provide a compiler which can build your project, and this compiler support run the command line to invoke it, so we can add the InvokeProcess activity(execute the command line) to invoke that compiler to build your project in build process template.
Here are useful blogs for your reference:
http://donovanbrown.com/post/I-need-to-build-a-project-that-is-not-supported-by-MSBuild
http://blogs.objectsharp.com/post/2011/03/31/TFS-Build-Invoke-Process-Activity.aspx
I have some existing install shield 2009 projects and every time i want to create a newer version of them i perform some specific tasks that i want to automate with a script.
This are the operations that i have to perform manually
Change GUID
Point to the updated packages
Build single_exec_image
Is it possible to make this operations from CLI on installShield 2009?
Thank you in advance
InstallShield has an Automation Interface (32bit COM based). You can use this API to make programmatic changes to your installer project. InstallShield also supports command line builds using ISCmdBld.exe.
Typically you do all of this in the realm of build automation using MSBuild or NAnt. Both allow you to write custom tasks in c# that can interop to the COM automation interface.
For example I use TFS which uses MSbuild (which InstallShield has native support for via .isproj files ) to build my installer. In this scenario I can use dynamic properties in MSBuild to generate a GUID and I can use path variable overrides to point to your source. The build target then builds the installer.
A bunch of ways to skin this cat depending on your environment.
I created a visual studio setup project. I want this project to install the output from another project into the path given by the user in the installation folder component. That is already working.
Now I want the installer to check if the output is already installed (perhaps that is going to work with the registry?). If it is already installed, some data from the old app.config should be merged into the new app.config (like connection data entries).
Is there a way to do this?
I found custom actions, but the code from my project does not seem to run:
http://msdn.microsoft.com/de-de/library/d9k65z2d.aspx
I simply try to write into the config file:
string path2Conf = "C:\\Program Files\\Proj\\app.conf";
StreamWriter sw = new StreamWriter(path2Conf);
sw.WriteLine("Hallo1298347645");
But after the installation there is not such a string in the config.
Edit: I added the custom action to install.
This is not supported by Visual Studio. Also, you can't do it through custom actions because a Visual Studio setup project doesn't support running actions before the upgrade starts. You would need to backup the original information before installing your new XML.
If this issue is a show stopper, a solution is to use another setup authoring tool which supports XML updates or at least offers more control over custom actions.
If you want a free tool I recommend WiX. It has a steep learning curve but it gets the job done.