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).
Related
I think I have various beads on why this may be happening, but I can't quite put all the clues together.
We were building an ASP.NET app in VS 2019 with a nuget dependency (Microsoft.Data.SqlClient.SNI.1.0.19235.1 if it matters). I've used msbuild -t:package and in VS 2019, it would spit out bin\x86 and bin\x64 folders with the DLL from that nuget package. That package step would spit out a zip file and opening that up you can see the x86/x64 folders in there.
We upgraded to VS 2022 and the CPU arch folders are no longer there. I can see them get created in the working directory, but not in the package output.
Nothing in the project has changed. It's set to target "AnyCPU" and Framework 4.6.2. The command we're using to build hasn't changed either. As far as I can tell, it's just the upgrade to VS 2022.
I know VS 2022 is now 64-bit native, so I have a suspicion that's in play here. Any ideas on why those CPU-architecture folders are no longer included in the zip package? And how to get them back in there?
Thanks!
According to your description I make some test, hope it can help you:
Check your Configuration Manager under Build in the menu and add new Platform you need.
Build the project in Batch Build under Build in the menu.
We can see that .dll files are created in the same path so it will be covered.
Open the project file.(Right click on the project and Unload Project then right click again an choose edit project file)
You can see code like this:
Change the OutputPath to “bin\x64\Debug\”, ”bin\x64\Release\” and so on.
Reload the project and rebuild the project in Batch Build.
About how to Pack multiple platforms into one package you can see this(Pack multiple platforms into one package, using dotnet pack ).
If it helps anyone, since my problem was specifically with the SNI.dll not being emitted in the x64/x86 folders, my workaround solution was to upgrade the Microsoft.Data.* libraries to a newer version. The x64/x86 folders are still not emitted, but I now see Microsoft.Data.SqlClient.SNI.x64.dll and Microsoft.Data.SqlClient.SNI.x86.dll files in the root bin folder.
It doesn't answer the original question, but at least it got me moving.
I have developed an opencv application using windows form and C#.
The opencv packages I got from the Nuget packages manager (EMGU.CV and ZedGraph).
Everything works fine in visual studio, but when I publish the project and install the program in my machine, it throws an exception when I click a button that performs some opencv operations.
I guess the opencv packages didn't come along with the final published project, so how do I do to make it export when publishing, I thought it would be an automated process, I have already used other nuget packages and I had no problem with it.
What Am I missing here?
After some days waiting for an answer, and looking for solutions, I've figured it out how to solve this issue.
I came across this question:The type initializer for 'Emgu.CV.CvInvoke' threw an exception
Which led me to this: http://www.emgu.com/wiki/index.php/Download_And_Installation#The_type_initializer_for_.27Emgu.CV.CvInvoke.27_threw_an_exception.
More precisely this part:
First of all, I don't know why the compilation runs fine inside visual studio enviroment and why not when publishing the project as it is. For some reason, the Nuget packges are not enough for publishing the project, you need to add the .dll files manually yourself (not sure why this occurs once I have worked with Nuget packages before and this workaround was not necessary).
To find the .dll files you go to your project directory, then you go to bin\Debug\x64 or bin\Debug\x86 (depends on which operating system you are targetting - 32 bits or 64 bits -in my case I added all .dll files from x86 folder, I guess you can add from both folders if in doubt).
The Debug folder of your project is build every time you run the project inside Visual Studio enviroment, so if your Debug folder is empty then you just need to run the project one time to be able to find the auto generated files inside that folder. Just a side note here, you can use either the Debug or the Release folder inside bin, just remember to check if you compiled the project in Debug mode for Debug folder, or Release mode for Release folder, otherwise the desired folder will be empty, as explained before, I found no differences between the files generated, I added the dll files from Debug\x86.
Once you have located the .dll files, you go to Visual Studio, right click on the project in the Solution Explorer tab, then Add ---> Existing Item.
Go to the folder where the .dll files are, select all and click Add.
Once you have done this, the .dll file will be shown in the Solution Explorer.
Right click on each .dll file added in the Solution Explorer, and open the properties tab by clicking Properties. On the Properties tab, go to option Copy to Directory and change the field to Copy Always (the emgu documentation link provided above states to use the option "Copy if newer", but to make sure I chose "Copy always", it worked fine for me). Repeat the process for all .dll files added.
Now you are ready to go for publishing the project as it is,just remember doing this every time before publishing your project to see if no .dll files are missing, so once you got to final version of your program, run it, and then make sure to check the .dll files, it might have new ones to add or to remove.
How can I make a solution in visual studio so that the .dll dependencies that reside in some other directory totally different from where the solution itself is affected by "get latest".
What I've tried is creating a Dependencies solution folder within the solution itself and added the dlls to it, that way they belong to the solution even though they don't belong to the directory structure of the solution.
So for example the .sln file is in:
D:\tfs\repository\main\SolutionA\solution.sln
and the dlls are in:
d:\tfs\repository\main\SolutionX\Dependencies\Binaries
What I really want to achieve is to have a foolproof way to build the solution, including the following scenario:
1- Have a brand new installation of windows, visual studio, etc.
2- open visual studio
3- find solution.sln on TFS, double click on it so that visual studio gets every project and files in the solution, and opens the solution
4- successfully build
What happens when I try the Dependencies solution folder approach and repeat the scenario above, it will get all the projects within the solution, opens it, but the dependencies solution contents won't be pulled from TFS (although Visual Studio shows them on Solution explorer), which I think is flawed.
Some suggestions that don't involve creating pre/post build scripts are appreciated.
When you attempt to open a solution for the first time using the TFS Source Control Explorer, you may find that not all of your dependencies will be retrieved - the squiggly line may be highlighting some of your missing References.
One work around is to...
SOLUTION SETUP
Checkout all of your source code from TFS (i.e. Main and all of the sub-directories)
Open your solution in Visual Studio (i.e. MyApplication.sln)
In the solution explorer, create a New Solution Folder called ThirdPartyDll, and then add the appropriate assembly references (i.e. Assembly1.dll, Assembly2.dll,...)
Check-in your solution to TFS
SAMPLE FILE STRUCTURE
Main
MyApplication.sln
Source
MyProjectA
MyProjectA.csproj
MyProjectB
MyProjectB.csproj
Dependencies
Assembly1.dll
Assembly2.dll
You've run into a limitation of the "Open from Source Control" functionality. If you added the solution to source control from Visual Studio you should have seen the following message:
"The project that you are attempting to add to source control may cause other source control users to have difficulty opening this solution or getting newer versions of it. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution."
Open from Source Control will create a workspace mapping for the solutions root directory (D:\tfs\repository\main\SolutionA) but not a separate one for the SolutionX folder which is a peer to SolutionA. On the "new" machine you will need to manually create a workspace mapping to d:\tfs\repository\main in order to get both the SolutionA and SolutionX folder.
Create a solution folder and add the dependencies to it, that way when VS gets latest for the solution it will download these files. A bit brittle as people will need to maintain that folder but it works.
Alternatively create a nuget package and use restore packages on build. It will require a couple of extra steps when you create a new developer box (your nuget package repo will need to be added) but it will work for all projects going forward and is less brittle than the solution folder method.
I have a visual studio 2010 project under mercurial. I use mercurial either via command line or TortoiseHG. I want to work on a new feature, so I clone the repo. But now I am confused, am I supposed to import an entire new project into VS2010 just to work on this feature? I tried importing the VS Solution that was cloned, but got lots of build errors from dependencies cannot be found errors, which I assume is because I am trying to load this cloned Solution just like the original Solution and some paths are wrong (no idea where though).
How are you supposed to use mercurial and VS2010?
Cloning produces an exact copy of the original repository.
The clone should work exactly the same way as the original repository, so you open your cloned solution exactly the same way as the original one.
If you get build errors in the cloned solution but not in the original one, there are probably some dependencies (=3rd party assemblies that your application needs to work properly) which exist in the original solution, but weren't committed to the repository.
So, when you clone the repository, the referenced files are missing in the clone...so the clone won't work.
Source control works the best way if you check in the complete solution, including all dependencies:
Make a "Libs" folder somewhere in your solution, put all your dependencies inside, reference those files from your solution and commit the whole "Libs" folder to the repository.
If you do it this way, you can clone the repository from a different machine and open the solution, without worrying about any dependencies...it just works.
It sounds like your root problem is that you're adding references using full paths rather than relative paths. You'll need to rectify that before branching is going to be easy for you. I usually make a "References" folder that is on the same folder level as the .sln file, but one level up from the individual projects, then branch the whole thing.
Example Folder Structure
MySolution
MySolution.sln
References
MyProject1
MyProject2
As for VS integration, I use TortoiseHG combined with VisualHG, it works great.
There is also Mercurial Toolbar
Other tools
This may or may not be related, but I've had to load hotfix KB2286556 in order to get rid of the "Unable to update project dependencies" error from VS2010 when building a fresh checkout of our code. It seems this only happens to setup and deployment projects when compilation is invoked from the command line (such as in our build system), but when it happens it's a very frustrating issue to find the solution for.
Also, VisualHg is a good way to track and invoke versioning from within Visual Studio.
While VisualHG still proves to be a wonderful tool after so many years, I would also suggest HgSccPackage as a very viable alternative for all Visual Studio versions (up to VS2015).
PROS: Stand-alone package (TortoiseHg is not required).
CONS: Doesn't have all the handy features of TortoiseHg such as Git support (which I find incredibly handy to handle GitHub-hosted projects) and Mercurial Keyring.
Both of them are freeware and can be installed through the Visual Studio GUI (Tools > Extensions and Updates...).
For a more extensive comparison between them you can also read this post on my blog.
I am currently trying to set up a new visual studio 2008 solution while using TFS.
Current structure is as follows
ProjectName
- src
* SomeSolution.sln
* ProjectFolder1
* ProjectFolder2
- Third Party Tools
In subversion I would just go to the root directory and do svn update. Or with Git, git pull origin from the root directory as well.
When in Visual Studio and I right click the solution and press "get latest version" I only get the latest src located in the solution. Is there a way withing Visual Studio where I could cleanly get the latest libraries as well? Or am I going to have to install the powertools on every developers machines so that they can update from windows explorer?
Using the Source Control window, right click on the ProjectName and select Get Latest Version
Or, add the Third Party files under a solution folder. That way you can continue using the file/directory structure you have set up, as well as be able to get latest just from getting latest on the solution file itself
As qntmfred said, Run Get Latest from the Source Control window. This is the only way to ensure that you get everything in the source tree you want.
We typically have an Assemblies folder in our main solution that all third party binaries used in that application are branched into. When the third part library is updated, we sync the branches with the relevant solutions that need them. All projects reference the assemblies from their locally branched copies. For example:
$TFS/
/ProjectName
SomeSolution.sln
/Assemblies
/Third Party (contains DLLs only)
/Websites
/ProjectFolder1
/ProjectFolder2
/Third Party Tools
/(tool name)
/bin
/src
You must install the TeamExplorer on all machines that access the TFS server. Just know this way. The "GetLastVersion" already overwrites files of the machine.