Due to the way open sourced softwares are published ( frequently, big changes ) I found It quite hard to find the original source code for the version I am using.
For example, this is one of the most used version for IdentityServer.
Lots of classes and implementation has been changed since. So I have to
1/ find the Nuget Package version.
2/ Go to the linked GitHub (or another repo) ( if available )
3/ Go to the release and hope to find the same release equal Nuget version number
4/ Download source code at that release
5/ Integrate the downloaded project into my project
Is this the standard process or there is easier / more straight forward way that I should be doing? A tool to directly pull the correct release of that open sourced Nuget package directly in Visual Studio even?
Is this the standard process or there is easier / more straight
forward way that I should be doing? A tool to directly pull the
correct release of that open sourced Nuget package directly in Visual
Studio even?
As far as I know, this is the most standard, normal, simple way to get source code of the open sourced nuget package. And there is no such VS extension or tool to get source code directly. What you list is the only formal, standard way.
Besides, the release and update of the source code is up to the author, and in my test, the latest version 4.0.0-preview.3.23 section has been committed to IdentityServer4 source code link. So you can build and debug the latest version.
Source code of all open nuget packages is published on the Github website and you can follow the guidance which is provided by the author to build and debug the source code.
For an example, when you access the nuget package IdentityServer4, you can click on the Source repository which is on the right part of the website to access the open source code link:
Related
I have the situation where our code base is like so:
/Gui/
/Product1/
/Calc engine/
/Core/
/Product2/
All of these projects are loaded into a Global solution file in Visual Studio.
I want to extract Core to it's own repo and allow different branches of this repo to load different versions of it. I cannot just use references to the binaries as engineers want to be able to debug the core code when running the Products so I have to be able to bring the entire Core codebase in.
Originally, I intended to use git submodules but I am investigating whether Nuget might be a better solution. I have removed /Core/ to it's own repo and created a Nuget package of the Core directory (it contains about 20 different C# projects).
Is there a way I can input this Nuget package into the Global Solution? It would need to put the code into the same directory as it used to rather than a package director.
Is there a way I can input this Nuget package into the Global Solution? It would need to put the code into the same directory as it used to rather than a package director.
You can change the Package Management to "Pakcage.config" in Options\Nuget Package Manager. The package will be stored in solution directory.
and right-click the solution in solution explorer then click "Manage Nuget Packages for Solution"
I want to use the https://github.com/FaceDetect/cnn_face_detection project stored on Github repository but it shows so many different files and no proper documentation is available. Can anyone tell me how to build that github project into an executable?
If the github project has releases or tag, like tornado releases on github.
Then you can run
pip install https://github.com/project_name/archive/version.tar.gz
like this:
pip install https://github.com/tornadoweb/tornado/archive/v4.3.0.tar.gz to install the github online project.
But when the project does't have release tab. You need clone the project and compile from source.
In most cases, you can run python setup.py install.
The question has a python tag. So take python project as an example.
GitHub is mostly used for code. in various languages
How to make any github project usable or executable is specific to the language and to the kind of the project itself.
Also it need to be careful with the license terms, the state of reliability and completeness of the project you intend to work on (i.e: github.com/leezivin/FaceDetection_CNN – snakecharmerb); The fact that the specific project you mention, at the time, do not have a README.md and a license file jet , let's suggest to contact the author or someone contribute/commit the sources for any further informations.
btw the project you mention appears to be a c++ language project; so you need to be able to compile and link it ( Clean an Rebuid ) in some form of executable; The specific repo: cnn_face_detection contains Visual Studio solutions and projects therefore the easy way could be by using Visual Studio and open/import the artifacts ( it depends by version of visual studio you eventually can use ).
It is also required:
to choose if you intend to trust ( or not to trust ) the code:
to take care to the paths of the dependencies referenced by the prj because likely they need to be changed to the actual paths were you clone ( download ) the sources on your own filesystem. if don't do that you may not be able to compile the solution (i.e the three projects contained in the repo ):
By looking around the project, you will find folders named "VC2010" and "VC2006". This is a good clue that this is a Microsoft Visual C (or Visual Studio) based project. Inside you will find .sln and .vcxproj files, which are "solution" and "project" files, according to this list
Download and install Visual Studio from here. There are several options, try the Community edition first.
Download the source code of the project from github. To keep it simple you can just use "Download ZIP" button on the project home page.
Run Visual Studio and follow these directions to open one of the solution (.sln) files:
On the File menu, click Open Solution. The Open Solution dialog box opens.
Navigate to the solution you want.
Click the solution folder, which displays and selects the solution file within the folder. If no solution file is visible, verify that the value in the Files of type list box is Solution Files.
Click Open.
Build using these instructions. At this point you either have an .exe or a .dll (depending on which project you're building).
We are currently migrating our source control to Visual Studio Online. A feature we had in our old system (SourceGear Vault) was to share projects between solutions. Although this created a folder for our Framework project in each solution it kept it up to date when changes were checked in.
This is useful to us as it allows us to work on the Framework code in all the Solutions that are using it. I know its better practice to just compile the dlls and reference them - at this point in development we want to continue having full code access and debugging in all the solutions using this core framework.
Any help very much appreciated.
You have a few equally valid options for handling shared projects:
Reference the same project from each solution that needs it.
This gives you full control over the source code of the shared project while you work on the consuming solution, and may allow for easier debugging.
The downside here is that maintenance and releases may become trickier if Solution A is being released on Thursday, but Solution B is being released in 3 months and is in the middle of a huge refactoring cycle that has significantly modified Shared Component X, and Shared Component X isn't stable enough to be released.
Reference shared components from an internal NuGet repo.
You set up your release pipeline to push the shared components into NuGet as part of your release process (ideally, using a purpose-built release management tool... Microsoft Release Management is what I have in mind here) -- you check the code in, project gets built. Release process packages it up and pushes it into NuGet as a "prerelease" version. You reference the latest version in anything that needs the latest version.
If you need to reference a known-good, stable version, you just make sure your project is configured to pull a specific version from NuGet.
When you're done, you've tested the shared thing, and you know everything is good, you approve the prerelease version, and the same binaries are repackaged into a "stable" version.
The downside here is that there are some additional software requirements, configuration, and training for your team. This would be my recommended approach.
Check binaries into source control.
I don't recommend this one -- you end up bloating your source control repo (and if you're using Git, it's an explicitly stated anti-pattern -- never put binaries into Git, it causes long-term severe performance problems), and it's never exactly clear which projects are using which versions of which assemblies. It's a maintenance nightmare.
(1) is the best approach if you're releasing everything in lockstep and don't have to worry about maintaining separate versions.
(2) is the best approach if #1 is false.
(3) is the best approach if #1 is false and you're a time traveler who is posting from 2006.
Have you considered implementing Symbol Server and Source Server indexing with the check-in binaries or NuGet repo approach? This allows you to easily get back to the source while debugging and it's coming from a single known location. Visual Studio Online and Team Foundation Server have built-in support for helping you out with getting this setup during your build process. Here's more information in a write-up here: Source Server and Symbol Server Support in Team Foundation Server and Visual Studio Online
Thanks for the responses. We actually found a solution that works well for us. We branch our framework project into the implementation projects when we want access to the code base. If not we just use the DLLs
If it is then altered and checked into the implementation project it can be merged back with the other Framework branches easily when ready.
This probably wouldn't work well if the Framework code was being developed heavily, as it is now its only undergoing small additions and tweaks so wont be plagued with merge issues.
I have to agree with the majority. I just ran into the same issue. I implemented the Nuget Gallery Site on the internal network. It was a pain to implement, but once implemented, it's easy to use. I created a class library project that implements ADO.Net and the EntityFramework. I bundled it into a NuGet package and uploaded it to the internal NuGet gallery. From there I was able to add a package source to the internal NuGet gallery and grab the package that I uploaded. Very simple and convenient.
I set up the NuGet Gallery with Visual Studios 2017. FYI: Make sure that building the project isn't part of the Publish. It will not render with a ViewHelper.cshtml error.
I created the projects with Visual Studios 2015. I ran the command prompt as administrator. I also had to copy the NuGet.exe file into the directory where the project file existed.
Check out the below links for more information.
NuGet Gallery
Hosting NuGet Gallery
Create and Publish Package
Creating a Package
Create .Net Standard Package
I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
We're using an internal feed for a number of packages. Today we noticed that Package Restore was no longer working. Every package failed with an error along the lines of this:
Unable to find version '...' of package '...'.
The project with issues had its first commit on 2013-10-04, at the time NuGet had version 2.7
Multiple people successfully cloned the source control repo, which had no binaries at all, and nobody recalls any problems with package restore. So either all of us are going insane, or this was working fine.
When I try to do a new clone today and update to that very first commit, I get the error above. Same thing with the most recent commit. This is with NuGet 2.8
These are the docs concerning Package Restore changes in 2.7:
Before any of the above steps are taken however, NuGet verifies that
consent is given on two levels:
Visual Studio is configured to 'Allow NuGet to download missing packages'
Visual Studio is configured to 'Automatically check for missing packages during build in Visual Studio'
Both items are checked in the VS options.
This approach to package restore offers several advantages:
No need to enable it for your project or solution. Visual Studio will automatically download missing packages before your projects are
built and team members don't need to understand NuGet Package Restore.
Yet this is exactly how we managed to solve the problem today: right clicking the solution and enabling Package Restore. This resulted in changes on multiple levels.
.csproj level
+ <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
+ <RestorePackages>true</RestorePackages>
.sln level
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".nuget", ".nuget", "{6FE1C500-523A-4E05-B72E-28F14DEDB055}"
+ ProjectSection(SolutionItems) = preProject
+ .nuget\NuGet.Config = .nuget\NuGet.Config
+ .nuget\NuGet.exe = .nuget\NuGet.exe
+ .nuget\NuGet.targets = .nuget\NuGet.targets
+ EndProjectSection
+EndProject
And lastly, the creation of .nuget\NuGet.Config, .nuget\nuget.exe and .nuget\NuGet.targets.
As a test I've also created a new solution and project. Now I
add one of the internal packages
build
close the solution
delete the packages, bin and obj directories (like our ignore file does)
open the solution
rebuild, and get the error mentioned in the beginning of the question
When I repeat these steps with a package from the official repo, everything works fine. No errors at all.
I've went over the release notes for 2.7.1, 2.7.2 and 2.8.0 but I don't see anything related to this. What's going on?
It's a confirmed bug in the current release of NuGet, but it's fixed in the nightly builds.
Workaround for now is to set Package source to All in the Package Manager Console.
This may be caused by the following issue: https://nuget.codeplex.com/workitem/4000
Related to this issue, the nuget.exe client would not follow redirects, so if your internal NuGet server is returning a 302 when attempting to download a package, the client would not follow it and result in nothing happening. It's worth double-checking with a Fiddler trace to see if the VS extension has the same behavior.