I have a C# project in MS Visual Studio 2008 that I would like to share on Google Code...I am not sure exactly which files I should be sharing on Google Code if I want to involve other contributors? What I am exactly unsure about is whether to share the entire solution folder or just the .cs files? And if it's the latter how does a contributor go about building the solution and the directory structure?
Thanks
Generally I would include the project file(s) and solution file(s) as part of the source code in a team environment (such as at work), especially if they contain anything that's needed for the proper building of the code (build events, DLL references, etc.). The user file(s) and suo file(s) and stuff like that aren't needed, those are user-specific. But this is in an environment where it can be safely assumed that everybody is using Visual Studio, even the same version.
The code itself doesn't need the project/solution files to be built, and the less you can depend on them the more open-source-friendly the project really is. If the code can be properly built from the command line, or with a tool such as NAnt, then an open source project may be better off with that. So, just from a separation of concerns perspective, try to keep the dependency on the project file(s) as light or non-existent as possible.
Overall, including the project file(s) and solution file(s) is fine if your intended audience is expected to be using Visual Studio.
Related
I have a visual studio 2019 solution with a few projects that consist of mostly c# class libraries. This solution is never 'deployed' and is always run locally by anyone who uses it. Part of what we do for one of our test projects to work is put certain dll's we use into our bin/Debug folder. One of these is Newtonsoft.Json.dll for example. We have a specific version of that dll that we're required to use.
This is something that is usually done once, the first time we run a test in that project. This all works fine. However, whenever there is a code change and the project builds, for whatever reason all the files that are in "C:\Program Files\IIS\Microsoft Web Deploy V3" are copied into our projects bin/Debug directory and overwriting any of the same files already there (Newtonsoft.Json.dll being one of them), and it's a different version which then breaks our projects dependency on that version of the dll. It's worth nothing there are also a bunch of random other files/folders in that Web Deploy directory that get copied over that our project does not need to be there.
I've checked all build events, and searched the entire solution to see if we reference that directory at all which we don't. I've tried googling similar issues, but almost all of what I can find is related to how to use Microsoft Web Deploy (which as far as I can tell we're not, and intentionally as I mentioned we don't deploy any of this code).
If anyone has any insight on this, it would be greatly appreciated!
Thanks,
Andy
I'm new to c#, and i'm stunned by the amount of files that are generated by my release output.
I wrote a REALLY simple program that i want to distribute, no external assets or anything special.
but still, there are 10-15 files generated (.dlls, .pdbs, .configs, etc. etc.)
I did a little research yesterday and i got the impression that it is simply not possible to clean up this mess without a REALLY big hassle?
i tried Fody (didn't work at all) and Tidybin (or something like that?) (created a lib folder and put everything there, which was nice, but the program stopped working and threw errors about the missing files)
I'm looking for a way to generate a clean release version.
ideally with JUST my exe, with all the dlls and other stuff embedded, but everything i read about that was just way above my head and overly complicated (why isn't this super easy to do???)
if that's not possible, i'd be happy with moving everything except the .exe in a lib folder. but that didn't seem to work. how do i update the path inside my application, so that those files can still be found? like i said, that plugin seemed to do half the job, while leaving all links like they were.
(side note: why is there not ANY KIND of ducomentation for all of these plugins? i really don't have the SLIGHTEST idea what to do)
thanks
If you have a simple application, there shouldn't really be that much in the folder.
Actually, there should be:
1 exe, 1 pdb (only for debug build), 1 exe.config file for the application
1 exe, 1 pdb (only for debug build), 1 exe.config file for the Visual Studio Host Process
If there is the System.Net.Http library referenced, this could create a folder with many localizations. If you don't use it: Remove the reference.
Please note that you do not need to deploy all these files! If the application only references framework DLLs, all you need is the .exe and .exe.config file.
DLLs will not be embedded, but if they are framework libraries, they should not be added to the output folder unless you set the "Copy Local" property of the reference. And you don't need to deploy them along with your application, as obviously they are installed along with the .NET framework on the target system anyway.
If you reference any DLLs that do not belong to the .NET Framework, you normally deploy them along with your application. It's easiest to put them in the folder along with your application, but you can also put them in the global assembly cache on the target system.
There are solutions that package the executable, third party DLLs and stuff into an EXE wrapper that is unpacked every time you start the application, but I advise against this. The user won't expect this to happen, virus scanners may block this and builtin mechanisms like .NET settings may not work properly for those solutions.
The easiest way to distribute your code is using InstallShield Visual Studio edition. (That is available with your Visual Studio license)
Download and register, then add a new distribution project to your solution.
InstallShield Limited Edition for Visual Studio
A wizard will help you by selecting the main distribution files. And it is a useful tool distributing new releases of your application.
As a second option I use is ClickOnce (Microsoft), but for specific internal applications.
ClickOnce Deployement
I am trying to set up a Visual Studio 2015 solution in the way that StyleCop checks for the C# style and once committed to the source control other developers don't need to do anything else to follow the same style rules and get the same errors/warnings from StyleCop automatically.
As the StyleCop documentation page and GitHub StyleCop describe (both actually say the same) under the title Team Development:
copy all of the files from {Program Files}\MSBuild\StyleCop into a custom folder
in my case under C:\Program Files (x86)\MSBuild\StyleCop\v4.7 there is just one file: StyleCop.Targets
Searching for any StyleCop.dll drives me to another folder (C:\Program Files (x86)\StyleCop 4.7) with many subfolders, dll's, xml, exe, lex...
Now my questions:
Which are exactly the needed files to be uploaded into the project and hence to the source control?
Which are the changes to be done in the configuration project?
Note:
Until now I see the contextual StyleCop menus that allow me to make code analysis and checks.
To use the install, you would need to have each developer install the StyleCop program on their machines, (and on any build server).
There is an easier way... instead use the StyleCop.MSBuild nuget package for each project:
This adds a StyleCop directive to each csproj, pointing at the instance within the packages folder, this means that it is transferable to each dev machine, and any build servers without them needing to do anything.
Then once there is no errors in a project, use StyleCop.Error.MSBuild to keep it that way, again from nuget:
This adds <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> to the csproj, but again keeps it within nuget which I personally find an easier way to track things.
I would like to make a backup copy of my Visual Studio 2013 MVC application which is only the source code. Such that I could open the solution on a new machine and have it compile after NuGet has downloaded the necessary packages and so on.
I realise that if the project was in TFS or similair I could go to the new machine and download it like that, however I am looking for a file copy solution.
Now while I could ZIP up the entire folder including binaries that seems like a sledge hammer approach. Having looked around there does not appear to be an easy way to do this. Has anyone got a solution or a utility I may have missed?
Use a version control system such as TFS, Subversion, PlasticSCM, git whatever. Seriously. Distributed VCSs like git or Mercurial will let you transport the whole repository easily.
If you insist on a pack&go approach, the ZIP tool of your choice will, most likely, support include / exclude rules based on file name patterns. For example, in Total Commander it's easy to exclude bin and obj folders.
I am not sure how this feature is called in English but there is something like Clean solution in Visual Studio. This will delete all the binaries and stuff that can be generated. I am not sure it will also delete NuGet downloads but you may give it a try. Afterwards, you can simply copy the project or solution folder.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)