We use Visual Studio and TFS to do version/Branch control.
I'm developing a monodroid application and I want my client to have a UAT version as well as a live version. The way (As far as I know) to allow this is to have different assembly names, but this is going to cause huge issues with me whenever I merge a branch.
Is there a good way to handle this kind of merging issue?
Ta
Ross
If you change the target package name, then that should enable you to deploy multiple copies of the same application to an Android device.
http://docs.xamarin.com/guides/android/advanced_topics/working_with_androidmanifest.xml
Each copy of the application should have separate copies of your assemblies - although they may share the Mono runtime assemblies if you deploy debug versions.
Related
I have considered using GitLab shared modules (one for each library) but that doesn't work because Visual Studio doesn't generate an assembly for each shared module.
If I create a separate repository for each shared project/library and include each project in the application solution then branching becomes a nightmare to manage.
It works but there must be a better way.
I have a .NET application in a Visual Studio solution which is a GitLab repository in itself. Also in that solution are three shared .NET library projects and each of them is a GitLab repository and each shared library project should create its own assembly. These shared library projects can be used by other .NET applications.
As I understand Visual Studio 2022 doesn't properly support multiple repositories in a solution.
So with that, if I want to branch the solution and its contents I have to branch 4 times: Once for the application and three times for the shared libraries. Which I think is error prone when switching between branches.
What would be nice is to branch once for the whole solution even though there are 4 repositories in a single solution.
in Gitlab?
It seems to me the issue would be the same in GitHub/BitBucket/Gitea/...
What would be nice is to branch once for the whole solution even though there are 4 repositories in a single solution.
That seems to suggest the use of a monorepo.
Note that Visual Studio 2022 is supposed to support multi-repo, but it is not quite there yet.
Amend, Stash, Branch switching & Network operations
Multi-repo support for Amend, Stash, Branch switching and network operations including Pull, Push, Fetch and Sync is coming to the Git Changes window in future iterations.
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 want to deploy other files, not sourcecode but additional files in debug mode than in release mode.
In our case, we are working with a file database. In debug mode a development database shall be deployed to a device, in release mode a release database.
I know there is a way, to do it utilizing pre- and postbuild events. but is there a way, just to configure both modes differently?
The language I use is C#, but does that make any diffeences in this case?
It is possible to add all kinds of files to a project, and these files can be copied to the output directory by visual studio. In my case, these files are then copied from output directory (bin\debug, bin\release) to a mobile device. So that works fine. Now for some reason, I just want file A being deployed (copied) when I press F5 in debug mode, and file B being deployed, when in release mode. It would be great, if I could achieve this by configuration. Or in other words, can a project have a link to fileA in debug mode and fileB in release mode.
You haven't specified exactly how this database is deployed - is it an embedded resource? Or just a file in the same directory? Or something that's actually installed/published? It also matters how the project itself is deployed but, some ideas to get you started:
If space and security aren't issues, you could just deploy both and use T4 templating engine on your config file to choose which one is loaded.
Next up is post-build steps as you mentioned. Sometimes it really is just easier (although it can be more complex if different developers have different development environments).
Depending on how you actually do the deployment, the publish/build/package mechanism might do it for you (eg WebDeploy, Setup projects, Install shield, etc).
One last option which is a bit hacky but should work... Put the each version of the database in a new project, then manually edit the project file so that the Debug build references one project while the Release build references the other (Note, that link is for plain Dlls not projects but the technique is the same).
All of the above assumes you're doing something .Net 3.0 or above with a strong weighting for VB or C#. You do need to provide more info, eg for all we know it's a .Net 1.1 Website, IronPython or even C++ which are completely different beasts.
We have a system that is largely written in PowerBuilder 11.5 and we are using a single StarTeam project to hold the source code.
Now we are wanting to add some related websites developed in ASP.NET with Visual Studio 2010 to source control as well. We would like them to be able to share the same set of Change Requests as the PowerBuilder code. Since in StarTeam Change Requests sets are tied to a StarTeam project this means we will have to put the web sites into the same StarTeam project as the PowerBuilder files.
Are there any pitfalls related to putting projects from different development environments into the same StarTeam project?
What we do with Merant and Subversion is create a folder within the project for the Pb code. So the code from a variety of places is in the same project, but there is a subfolder within the project for the different sources.
CRs are not limited to a single project. You can create CRs and share them wherever you want on the same server instance, even between projects. You'd need to be careful to not branch the shared version so any CR property changes are visible to both sides. This isn't automatic, but possible at least.
Having the two projects share a single view is probably easier, especially if a single change needs to edit files in both products.
We are looking for a Version Control System to change our current Source Safe one. We are using it along with Visual Studio. We've failed so far - and the main reason for it is that all the alternatives we see doesn't support one or more features of VSS, especially one that we use widely - file share! What's up with that?
Alternatives like Source Gear claim to support them, but I gotta tell you that they do that very poorly. Not to mention that they are way slower than Source Safe, and have even more bugs.
What alternatives we do have to source version systems that do support file share? Or is there a reason to not use features like this? Please share your experience and support your comments.
EDIT:
By Share File I mean that I can checkout a file from any project that is sharing it, do some changes and then all get the latest version. It is very useful when working with C++ projects, or even C# Web Projects. I want to be able to share a file without the need to make another library for that.
From MSDN:
Sharing Files or Projects
Visual SourceSafe has a Share command that allows sharing of files or projects. For use of the command, see How to: Share an Item.
When you request file sharing, Visual SourceSafe creates a shared link between the versions of the file in the projects that share the file. When you check in the file to one of the projects, your changes are automatically checked in to all the sharing projects. All the projects that share a specific file are listed in the Links tab for the file.
When you share a Visual SourceSafe project, you create a completely new duplicate project under the current project. All the files in the new project are shared with the corresponding file copies in the shared project, and changes in one are reflected in the other during check-ins to the Visual SourceSafe database.
Other tools do have similar concepts, though not always with the same name or exactly the same semantics. Off the top of my head:
Subversion externals
MKS SI (shudder) calls them shared sub-projects
I tend to avoid them because it indicates there are some other issues with my project. If the resources are needed across many projects, I package them as a library and set my other projects to depend upon that artifact (using a dependency management tool such as Maven or Ivy to manage the dependencies)
In Subversion, you can share a whole folder (and its subfolders of course) with the svn:external property.
And since version 1.6 you can also share files.
In Git, those are called "submodules" - not sure if they work for single files though.
This post http://blogs.msdn.com/ericlee/archive/2006/07/20/sharing-files-in-team-foundation-server.aspx shows how you can accomplish the same thing with Visual Studio and TFS.
In StarTeam you can share files across projects.
I apologize if this is not really addressing the original question but depending on your will to "change mindset" for which version control system to use I would strongly suggest moving to a distributed one such as Mercurial or Git. There are plug-ins for Windows Explorer and Visual Studio for both.
As to specific features such as VSS-style file sharing I suggest setting up a Continous Integration environment like TeamCity and configure it appropriately.
It's a steep curve at first but awesome and time-efficient once your staff and servers know what to do.