I am having a hard time adding a Visual Studio Solution with multiple projects to my repo. I am using VisualSVN. Here is my directory structure
c:\-----
|
---Projects
|
--MyApp
|
---Project1 (The solution is in this project directory)
---Project2
---Project3
When I select "MyApp" as the working copy root, nothing is added. If I select one of the project folder, only 2 are added.
Here's the structure I use with success:
dev
|- Project root folder (solution file here is the key)
|- Class Project
|- Class Project
|- Web Project
|- References
|- Resources
What I'm suggesting is that you should move your .sln file to the top level then import.
Another advance approach.
Each project has it is own trunk with following structure
trunk
|- .sln
|- src
|- ClassProject
|- Web Project
Then in a separate svn directory create sub directory for every solution you need. For example you can have AllProjects, WebOnly, DALOnly.
And using svn:externals bring every project you need (ClassProject etc.) in given case.
Related
I have two projects A,B with their own build chains defined in their local .teamcity folders. In addition, A contains a dependency on B which I want to test. How do I set up a build chain that incorporates both of these individual builds such that, when B changes I test integration with A's master branch? I imagine I would first set up a second VCS root in B directed at the master branch of A such that the project structure on the agent looks as follows:
root
|-- A
| `-- .teamcity
| |-- settings.kts
| `-- /kotlin_code
`-- B
`-- .teamcity
|-- settings.kts
`-- /kotlin_code
But I have no idea how to automatically combine project settings from A into the B build chain. I perhaps could jerry-rig some checkout rule +:A/.teamcity/kotlin_code => B/.teamcity/kotlin_code_A and pick this up in B but this seems rather inelegant. I could also place all teamcity configuration in a separate repo, but then I lose revision control between A's codebase and its teamcity configuration. Is there a better solution? Many thanks!
https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360004237439-Re-use-build-configuration-in-multiple-build-chains
The answer here recommends creating a template under root that encapsulates most of the functionality of B and from this generating separate build chains in A,B. I am not sure this is the most elegant solution, however, so I will leave the question open.
The best answer I have found is to define a finish build trigger that starts when the previous build completes and send a reverse dependency back through the build chain to allowing builds to be customized.
My question is related to the structure or approach of Go applications. I have got the following application.
root
|- app
| |- services
| |- repositories
| |- handlers
| |- commands
|- go.mod
|- main.go
The Go files in the commands package are working independently. The rest of the packages are working for a web application. I start an HTTP web server in the main.go
So, I'd like to run the Go files in the commands packages in the crontab. But as I know, I'll build these whole packages into a single binary file. My question is how can I run the Go files in the commands packages independently in the crontab? I think I should separate them into 2 applications such as "web app" and "command app" but actually they are related to each other and I don't want to manage 2 apps differently. May I use commands Go files in the crontab and on the other hand start an HTTP web server in the main.go?
There's no reason why you can't import packages from your web application module into another one, but if you want to keep them together, you can just do what is quite common, and add additional main packages in specific directories, giving a directory structure like this:
root
|- app
| |-services
| |-...
|- cmd
| |- tools
| | |- main.go
|- main.go
You can build/install your CLI binary simply by running go build ./cmd/tools or go install ./cmd/tools
I currently want to add some self written classes ("mycode.cpp" and "mycode.hpp") to a big existing C++ project that is configured with Cmake. These classes are located in "myfolder" which is located in the "lib/pointrender" folder of the existing project (see dummy hierarchy below).
|- libs
| |- core
| | |- ...
| |- pointrender
| |- myfolder
| | |- mycode.cpp
| | |- mycode.hpp
| |- existingclasses.cpp
| |- existingclasses.hpp
| |- project.cmake
|- CMakeLists.txt
In the CMakesLists.txt the pointrender folder is declared as a subproject.
declare_subproject(libs/pointrender)
How do I best add my code to the existing cmake configuration? Do I add it as a subfolder in the project.cmake with a seperate CMakeLists.txt in myfolder? Or do I best add it as a subproject with a seperate project.cmake file? What's the difference?
This project.cmake is being include()d be some CMakeLists.txt and get's executed as part of it. Authors of project you are using rolled this out for some reason, so it's probably better to use their infrastructure to add custom code.
The usual way to do this is writing your own CMakeLists.txt and add_subdirectory()ing it from the upper level.
If you wish more details you should update your question with project.cmake contents.
I don't know if I totally got the concept wrong, but I want to create several projects with dependencies to other projects which are not part of the directory structure of a parent project. I know that the normal way of doing this would be to use an external dependency which fetches from some external repository. But in this case, where let's say in project called 'F' a framework is developed, which is used in project 'P'., then P uses F, but F should IMO not necessarily be a sub-project of P as P is only used to test-drive the development of F (but it's not only a unit test). Later in the process, when F is stable, F is separated and can be consumed by other projects via a repository. But during development of F with P as it's test case, it would be nice if that round-trip through the repository could be omitted.
To make matters worse, for the initial development there is more than one test-driving consumer project, which all need to have a dependency to F, but not via an external repository.
My idea is to develop F in some place on the disk with it's own git reposity. The other P like projects reside somewhere else on the disk and have a local file system based dependency to F. Would such a construct be possible in Gradle? If so, where do I start? I scanned the Java examples but couldn't find an appropriate example.
Any ideas?
The Gradle project hierarchy is fully virtual. It just has the default that the physical location corresponds to the virtual hierarchy. But you have complete control over this. See: http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html#sec:settings_file
Regarding your other ideas have a look at the following Jira: http://jira.codehaus.org/browse/GRADLE-1014
You could consider a folder hierarchy like this one:
Main folder
|- F folder
| |- .git
| |- sources
| |- build.gradle (with parts specific to F)
|- P folder
| |- sources
| |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle
So you can always decide to run gradle on either the F project, the P project or the two alltoegether. It will also allows you to promote you F project alone without the P or any other side projects.
For more up-to-date information, check the Multi Project Builds chapter of the Gradle documentation.
In Visual Studio when I linked a file from one project to the next, I get the following error when an attempt is made to load the linked resource. This only happens when the linked file is within a folder(s).
Error:
Message="'pack://application:,,,/projectName ;component/ResourceDictionary .xaml' value cannot be assigned to property 'Source' of object 'System.Windows.SharedResourceDictionary'.
Example:
Project1.Resources
|
|--> MergedResourceDictionary.xaml
|--> ProjectResourceDictionary.xaml
|--> Folder
|
|--> SharedResourceDictionary.xaml
Project2.Resources
|
|--> MergedResourceDictionary.xaml
|--> ProjectResourceDictionary.xaml
|--> Folder
|
|--> SharedResourceDictionary.xaml **LINKED**
If in the MergedResourceDictionary.xaml we merged these dictionaries, then the "SharedResourceDictionary.xaml in Project2 will not be found. However, if the SharedResourceDictionary.xaml is linked at the root of the project then the resource is found at runtime.
**NOTE: In the "obj/debug" of project2, all linked resources are at the root directory, whereas in project1 resources remain within the folder structure assigned in the project.
Steps to recreate
This happens at runtime. Steps are as follows (using files listed in original post).
1) Create SharedResourceDictionary in Project1, within "Folder"
2) Create "Folder" in Project2, then add "as link" SharedResourceDictionary within the folder
3) Build and run app
4) App will not be able to find the SharedResourceDictionary.xaml, due to it residing within the Folder. Removing the file from the folder structure will work fine as a linked file.
I appreciate any assistance,
Chris
I spent sometime working with Microsoft support on this problem. It is a bug with MsBuild and doubtful to be something they fix in the future.
I have found a workaround for anyone that is interested:
Create a PostBuild event that runs LocBaml and creates the folder structure that you require and places the files in the correct folder.
Hope this helps.