I've been writing a game for not so long now, but the code is already getting incredibly messy, because the full game is one program in my solution. Is there a way for me to split my game into multiple programs, like subroutines, but every program has its own tab within the solution? (I'm working in Visual Studio) If there indeed is a way to do that, how would I do that? I'm still a beginner, so it would be a great help if you would explain it a bit more thoroughly than usual. Thank you in advance!
Need to think the difference between solution and project.
Solution is the entire code that solves the problem you have.
Project is a part of a solution.
Segment out your code into projects. UI in one project, 'Common' stuff in another, Back-end in another, etc.
You can have the projects reference the other projects they need to get the job done (just can't have Circular references, ie. A->B->A).
Related
First of all, thanks very much for having me in this community! :D
Secondly, let's go straight to the issue!
Today, I'm the unique responsible for a bunch of projects, and after some time, we decided to delegate these projects to other employees, because many times the code modification isn't needed to be made by me, the technician can do it easily. For today, each code modification is delegated to me, so in that way, its easy to control the Projects.
Then if we start working with more people, it will be more difficult to control these projects. Then I wondered (haha) that why don't use Git as our project controller?
I started deveolping an application that uses LibGit2Sharp (which is great!) for controlling the projects, but then I realized that I'll have to create tons of projects for controlling each one. And each projects is more like a configuration file, not development. It would be great if all these projects could be controlled in the same project (as a submodule, for example). I started looking for what submodules gives me and I don't think is the same as I need.
The project structure would be like this:
/Master Project
/.git
/MySoftwareV1
/Customer1
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer2
...
/Customer3
...
/Customer4
...
/MySoftwareV2
/Customer5
/.git
ConfigFile1.cfg
ConfigFile2.cfg
ConfigFile3.cfg
/Customer6
...
/Customer7
...
/Customer8
...
Is it possible to implement?
In this case, my application will control the submodules for the users check-out/in.
If you guys need more information, please don't hesitate to tell me!
Thanks in advance!
Best Regards
I would keep it simple, use a single Git repository without fancy stuff like submodules and instead mirror the project structure as a file folder hierarchy.
If you want to have more control on what the technicians do, you could let each one of them work on their own branch, so they can't damage someone else's work. It would be your (or your LibGit2Sharp-based application's) task to review their changes and to merge them to the master branch.
Since Git keeps track of the whole change history, you can always undo unwanted changes.
We have two projects underway and want to share some classes between them. The shared source must be in a single location so when a programmer on Project1 updates the code those changes are immediately seen in Project2.
The important part is that we do not want to maintain multiple copies of the same code. i think we would agree that its simply bad practise to do so.
The only option appears to be putting the code in a class library and load it as a plugin into each project. But I don't believe this works when referencing Unity types like GameObject or transform.
In C/C++ land we could put the source in a directory and include it into any solution we wanted - doesn't seem to be so easy in Unity-land. Is their a better way to share code between unity projects?
EDIT: All projects, including the shared code, are already under source control. This is not a Source Control question, its a framework issue. (And obviously I need to write better questions!)
Lets say the directory structure looks like this...
C:\
Project1\
Assets\
CodeForProject1\
StandardAssets\
Library\
C:\
Project2\
Assets\
CodeForProject2\
Resources\
Library\
D:\
UsefulCode\
PlayerClass\
WeaponsClass\
DataAccessClass\
Can Unity reference code from other projects? Can Unity reference code outside of its own Assets folder? If so, how?
I understand exactly what you're facing, we faced the same problem here some time ago.
The idea of our shared code is to be sort of a middleware, so it is natural that it will evolve through. Our solution was to create a git module for the shared code. I know you said that it's not a source control question, but at least here in my company, create a dll was not a good solution since we are changing the shared code constantly (we tried soft-links too, but it was very painful to maintain in all machines).
Here we created two projects: one for the middleware and another just for the tests. The last one have only the gitmodule to the middleware and a bunch of unit tests. We did it to ensure that there is no dependency to other projects. Both are in the source control. So when someone wants to implement a new feature inside the middleware, he/she make it inside the tests project, and when it's done commits to both projects.
Oh! And you can make a dll with Unity types and use them normally.
Firstly, I'm new to VSTS and Git, so apologies if my terminology gets muddled!
PROBLEM
My situation is that I have a VS/C# Project (called "PluginBase") that is, essentially, "starting template" code for a plugin. Historically, I've would just copy that PluginBase project code every time I wanted to create a new "tailored/derived" build for a particular customer.
What I would like to be able to do is, as and when bug fixes are resolved and features are added to the PluginBase project, I'd like the option to migrate these changes to one or more of the "tailored/derived" builds. Likewise, if the bug was first found while developing a "tailored/derived" build, I'd like to migrate that back to the PluginBase plugin.
IDEAS
From my research, I've come across a few "possible" ways of achieving my goal, but I'm not sure which (if any) of these approaches are suitable.
Branches
Seems the common approach, perhaps the "best", but...
Means all code must be in the same repository? (otherwise can't "cherry pick" across) - which I'd prefer to avoid as this may not always be possible
Git Submodules
Seems more intended when projects are sharing a common "library" (not deriving from same code-base)
Also not sure Visual Studio fully supports this feature
Cherry Pick
Doesn't seem possible to do this from one repository to another?
Git Patch
Doesn't seem Visual Studio supports this feature yet?
So, if anyone has any advice, guidance or new suggestions for approaches I could (or should) be using, I'd really appreciate your input.
Many thanks! :)
Git Branches are definitely the way to go. The code indeed has to be in the same repository, git stores change sets and in order for a change set to be applied git has to know what happened since the code-paths split or it can not replace the correct lines of code.
Make a branch for each time you roll out a version to a customer, you can then cherry-pick across the different branches.
I am trying to automatically open an NDepend Project when the Solution builds in an automated build in TFS2010.
This stems from this previous question. The aforementioned post is where I tried (and failed) to integrate NDepend's code metrics software with an automated Team Build via messing with the XML of my solution.
I decided since I wasn't getting anywhere in messing with the XML, that I would try a different route. In another program I have developed, I used
System.Diagnostics.Process.Start("blah.txt");
to trigger Notepad to run and open the text file "blah.txt."
I figured I could use the same concept to possibly help me with this NDepend integration. So I researched MSDN to see if I can find out more about the Process.Start method. And using this example
Process.Start("IExplore.exe", "C:\\myPath\\myFile.htm");
I substituted in my own paths to what I believe should open the project file "myProj.ndproj" inside the VisualNDepend application like this
System.Diagnostics.Process.Start("C:\\tools\\NDepend\\VisualNDepend","C:\\myProj\\myProj.ndproj");
I may be taking that example and tweaking it out of context, I'm not sure, but it seemed to me that what I tried should work. The solution built fine without any errors, but VisualNDepend didn't run.
It finally hit me that I was trying to use this code that would only execute when the program ran when I really need it to execute when the program builds within TFS and Visual Studio.
I asked my coworkers if they knew of any built-in ways within TFS or VS that would recognize whether or not the solution was being built or not. And they didn't really know of anything in particular. I tried "Googling" this topic and couldn't find any information that was useful to me.
Does anyone know of how to accomplish this? Or am I chasing a lost cause by trying to execute some C# code behind the solution? In which case, is my best bet trying to tweak the XML like I had previously been attempting?
I would recommend writing a custom build task (or tasks). You can essentially make the task do anything you'd like -- run a process, spit out results, etc., and it can be invoked directly from your MSBuild script.
I'm not sure if I'm answering your question (or if I even have a grasp on what you're trying to do), but that's probably the area I'd be looking to find my solution.
I'm a newbie to SSIS / C# (I'm generally a Java developer) so apologies if this is a really stupid question.
Essentially the problem is this: I have two Data Flow tasks which load data up and export them to a legacy flat file format. The formatting is done by a Script Task (C#).
What I'd like to do is share some common code between the two. e.g. I could create a common base class and then extend it for my two different script tasks.
However it seems that SSIS doesn't really make provision for this.
Does anyone know if there is a way of accomplishing what I want to do?
You're correct that there is not a straightforward way to do this directly from SSIS.
In a recent project, we took two different approaches, which both worked fairly well depending on what you need to do:
Create a utility class (as a simple class library) and reference it from your script tasks. This is done pretty much the same as any other sort of reference. If you use .NET 3.5, remember that you'll have to update the version manually in the script tasks since SSIS defaults to 2.0. We also found that if we wanted some manner of reusability in the utility assembly (not relying on hardcoded variable names, etc.) then the package still had to have a fairly large amount of "setup" boilerplate to use the utility scripts.
Create a custom data flow component. This is a much more involved process, but ultimately will do the best in terms of avoiding code duplication. Generally, coding the actual data flow is fairly simple and not that much different than a script component, but the various setup code you'll need can tend to make things complicated. There's also not a lot of support in SSIS for when something goes wrong. Led to a lot of detective work on our project.
If you plan on using something a whole lot, and are committed to getting rid of boilerplate code as much as possible, 2 is the preferred option. If it's being used a few places here and there, consider the simple approach of 1.
I am pretty sure it's possible to access .NET assemblies in SSIS scripts. So you could do it this way. See the article "Accessing .NET assemblies with SSIS" on SQL Server Central.
I believe you will have to create an assembly or webservice for this to work.
This does not completely solve your issue but it does help in not having to recreate all the classes every time you need them (I also do not want to deploy referenced assemblies for my current project ). Firstly you need a master copy of your classes, you can copy them from an existing Script Task using the same process below but in reverse.
Open the Editor for the Script Task and on the Property Explorer click on the Project File (the st_[Guid] ), in the Properties window you’ll see the Project Folder location. (This location gets recreated every time you edit the script task)
In explorer, copy your classes to this folder
On the Project Explorer, click on the “Show All Files” icon
Right click on your files and add to Project
Probably way too late to answer this, but you can click on the solution and add a class there. Then when you go into your scripts you can say add existing object and search for that class you created earlier. For me it was located by the solution for the project. Haven't gone through the deployment or anything for this, but at least you can access the class through the individual scripts.