I don't know much about NuGet, I only used it a few times to download a few things into my Visual Studio projects. I need to make a command, that can be entered into the Package Manager Console in Visual Studio, that would then create a solution with a variable number of C# projects in it (the variable would be passed as an argument in the command). I've seen it done before, but I have no idea where to start.
You could look at how Entity Framework does it - http://entityframework.codeplex.com
Related
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.
I am trying to run multiple apps with the same code, the only differences are application names, icons and the splashscreen.
I am already 100 % sure that my approach must be complete crap, but here is my approach:
I copied the excisting project specific configuring files, changed all file names to the new project, replaced references inside these files and imported this project back to the solution, because creating a complete new product within the solutions ignores all yet created files so I wanted to save some time. Now have 1 solution (I thought of this as the product) and 1 projekt for each customer, all targets sharing all code, except the project configs with the ids, names and icons etc..
But when I try to build any of the project I get these errors
Error occurred while restoring NuGet packages:
The process cannot access the file
'C:\...\project.lock.json'
because it is being used by another process.
Or the assembly is used by another application.
So, this can't be the right way to do what I want to do by Visual Studio, I'm looking for the right way to handle 1 base-product but many customer-specific-apps with Visual Studio 2015.
Sadly I couldn't find any tutorial for that yet.
Maybe I'm searching with the wrong description or naming, I thought of projects as targets in Xcode.
A link to a proper tutorial would already do the job for me.
Thanks!
According to your description, I think what you want is building multiple branded apps from a single Visual Studio solution. If so, here is a nice article: Multi-Branded Apps in Visual Studio (Windows 10 UWP) you can refer to.
The key point here is using separate build configurations for each app and then using Pre-build commands to create the app package.
For more info, please see Understanding Build Configurations and Specifying Custom Build Events in Visual Studio.
Where I work, we've gone to great lengths to create a build script in Fake that does a whole host of things, so that developers can check what's going to happen on the TeamCity server before committing. It's great when run from the command line, but I'd really like the ability to have that script called when doing a build from within Visual Studio.
From my own research, I've not found anything that currently allows this, nor have I found any VSIX that does what I want. I'm currently running on the assumption that if I want to proceed with this thinking, that I will need to write a VS Extension myself.
Does anyone here know of any existing VSIX, or any way to change the default behaviour of build?
For reference, target VS is 2015.
If it's just parameters you're trying to pass eg.
code.exe -b
Then you can change the build settings in the solution under properties>debug.
Prior Visual Studio 2015 and nuget 3.x, there was the possibility to have some nuget packages at the solution level. Now with nuget 3, this as been deprecated. You could find the reference of this here : https://github.com/NuGet/Home/issues/522
This cause problem in our case since we used to have a nuget on the solution level that is loaded with a init.ps1 script when solution load. In fact now, with VS2015, it doesn't get run anymore.
My question, pretty simple, is there another way to achieve that behavior in VS2015 when opening a solution?
While searching for something similar I found your question and this one
which appears to directly answer your question.
In short, create a powershell script (or use the one you have) to create a Nuget package, and then import that package into one of your projects. Each time the project is opened the script will get executed.
I create a new custom project type using a VSPackage project inheriting of MPF library (http://mpfproj11.codeplex.com/). As a result I obtain a .vsix but I need add this project type using a .msi. I'm using the Visual Studio 2010 Setup projet for it. In my setup project I add the content of the VS Package in the same directory where the .vsix put then, but I think Ineed to put in the registre the new type of project because when I use the setup , the project template does not come out in Visual Studio and when I give double click the file with extension of the type of new project and does not recognize it. When I look the registry after install the vsix, this was one of the things that I found diferent. I add this entries in my setup project but It's not working yet.I'm missing something else?
In the projecttemplatedir is the directory where I put the .dll of the project type, the vsixmifest and pkgdef. The project template is in [User]\Documents\Visual Studio 2013\Templates\ProjectTemplates\[Name of new Project Type]\[projecttemplate.zip]
Best Regards
PS: The project type is for VS 2013 but I'm using the VS 2010 Setup project ;)
OK, so first the "don't"s of doing this:
In general, if you are installing via MSI you shouldn't be doing anything user-specific -- no writing in HKEY_CURRENT_USER, nor writing within their Documents folder, LocalAppData, or Visual Studio folders, etc. If you see yourself writing files or registry keys in either of those places, that should be your hint that there's a better way to do what you're trying to do. For what you've shown so far, this raises more than a few red flags for me.
Second, don't ever go writing keys into 12.0_Config. That part of the hive is nothing more than a cache that's built up from other parts of the registry and on-disk .pkgdef files from extensions. It's rebuilt in any number of senarios, including installing new extensions. Any writes there you should presume will get blown away at any time. If you need to write things there you should either (a) write in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\[version] and run devenv /setup or (2) [preferred] put your keys in a .pkgdef inside your extension which gets merged into 12.0_Config for you automatically.
Now the dos:
You said you already had a .vsix produced by the SDK: you can put project templates in there. You can then register those templates in the .vsixmanifest and those will pull in. That's far easier than mucking around with files in Documents -- that's the user's directory...don't go playing with that.
Once you have a .vsix that does most of what you need, you should simply take the files within that and install the files in a folder within C:\Program Files [(x86)]\Microsoft Visual Studio 12.0\Common7\IDE\Extensions. Even better, you might just want to WiX toolset to build your installer, since it has built-in support for installing extensions. It also has built-in support for invoking the "/setup" process if that's what you need to do as well. Visual Studio Setup projects are no longer supported in newer versions of Visual Studio, so you're better off starting with a technology that isn't already obsolete. WiX is even what we use at Microsoft to do the setup work for Visual Studio itself, so it's definitely up to the task.
Last point: almost everything when it comes to Visual Studio extensibility can be done with a VSIX directly, so presume there's a good way to do something that way before falling back to an MSI. Internally, we can register the entire C# and VB language services with just a VSIX -- they're quite powerful.
I found the answer in this link Registering Project and Item Templates. I set projecttemplatedir entry with
[User]\Documents\Visual Studio 2013\Templates\ProjectTemplates[Name of new Project Type][projecttemplate.zip] that is where i put the project template.