TheSwamp
Code Red => .NET => Topic started by: TJK44 on May 29, 2012, 10:59:11 AM
-
I'm aware of the changes made in 2013, specifically the extra dll needed in 2013 .NET projects. My question is maybe a dumb question but what is the best way to keep a copy of my 2012 project and make another for 2013. There is no 'SaveAs' in Visual Studio so this is why I'm asking. I want to convert my code to work with 2013 but also be able to use the old 2012 code also.
Thanks for any input,
Ted
-
I'm aware of the changes made in 2013, specifically the extra dll needed in 2013 .NET projects. My question is maybe a dumb question but what is the best way to keep a copy of my 2012 project and make another for 2013. There is no 'SaveAs' in Visual Studio so this is why I'm asking. I want to convert my code to work with 2013 but also be able to use the old 2012 code also.
Thanks for any input,
Ted
What I usually do is create separate projects and add all shared source files using 'Add As Link', and keep the shared source files out of any referencing project's directory tree.
http://www.dimecasts.net/Content/WatchEpisode/10
-
I haven't used (didn't know about) the 'Add As Link' option. What advantages is there using the Add As Link vs. simply copying the project file in the same directory and giving it a new name? Will leaving both projects and all source files in the same directory cause issues?
-
I haven't used (didn't know about) the 'Add As Link' option. What advantages is there using the Add As Link vs. simply copying the project file in the same directory and giving it a new name? Will leaving both projects and all source files in the same directory cause issues?
I can't tell you since I've never done that. I would imagine that there would be some issues related to what goes into the /bin and /obj folders, but can't say for sure.
The advantage should be clear in more complex scenarios. In some cases a project may share some but not all source files with one or more other projects. I don't really think you would want to deal with the rats nest that would result if you tried to place all projects that share some files with other projects in a single folder.
In my case, there are many projects sharing source code files, and I wouldn't want to have to put all of those projects in a single folder in order to share source code between them.
You can keep source code files in one project, and add them as links in any number of other projects.
-
Never used it and would take Tony's advice but just to throw it out there if you select a project, solution, class etc.. in the solution explorer then in the 'File' menu there will be a 'Save As' app.sln, app.csproj, class.cs, etc.. or whatever you had selected in on the file menu.
-
I do value Tony’s advice, but I am looking more at the OP’s original question. From what I gathered from the original question is this: I have a solution filled with projects, which all target .NET 3.5 which works great for AutoCAD 2012 and below. Now I want all of my source code to work in AutoCAD 2013… how do we do this? Well from what I understand AutoCAD 2013 requires .NET 4.0 and also requires an additional reference, so my thought was to simply copy the solution file and every project file in the solution. Open that solution and change the projects to target .NET 4.0 and replace and add the additional references for AutoCAD 2013. We would also have to add some compiler variables to handle the changes in namespaces/classes/extension methods for AutoCAD 2013 compared to prior releases. Doing as I described allows me to compile the first solution (targeting .NET 3.5 and AutoCAD 2012) add those assemblies to the install project and then compile the next solution (targeting .NET 4.0 and AutoCAD 2013) and add those assemblies to the AutoCAD 2013 install.
Tony, I’m not asking these questions to get in a debate with you; I’m asking because I have a solution filled with projects that all point to .NET 3.5 and work fine in AutoCAD 2012 and below. We now have to work with AutoCAD 2013 and from what I see the only change we need to make is as I described above or by using Add as Link. As I stated in my first post I wasn’t aware of the Add as Link option so I do not want to be caught off guard if what I am attempting is futile.
-
This seemed to work for me. I copied the entire folder that contains the solution, bin folder, all forms, etc into a new folder location. Referenced the AutoCAD 2013 files and rebuilt the solution and it worked in 2013. And my old 2012 code still works also.
-
Copying a solution is a good way. All file references in a solution are relative, even outside the solution (if you have a map in the root with Object ARX files and you reference the dlls in that map) as long as the files are on the same disk. But it is wise to check all file references for sure.
I don't think you can maintain a version for AutoCAD 2012 and one for 2013 with just adding source files as link. There are many small and large differences in namespaces and functions, also in AutoCAD and certainly Civil3D 2013 there is more functionality. So if you need to change little things in a source file which is also referenced in a 2012 version, it would probably not build. I can't imagine you can solve that with conditional constants.
I've decided to copy all solutions of our commercial software and keep the current versions intact for use in 2012 and below, and I will not put new functionality in it. The copied solutions get a higher version and are only available for 2013, and new functionality I will put in this version.
Using source files as link is a great option, I use a lot of source files with shared functions and forms, like authentication forms. I keep them in a map "shared" outside any solution, so there is no main solution where the files are in. If I accidentally forget the Add as link, any to-be-shared source file in a solution can be removed and added again, but then as link.
But I've also copied the map with the shared source files for the 2013 versions and don't share them with 2012 solutions.
This way I am sure I keep 2012 and 2013 versions seperate.
-
Copy As Link works better for me because it allows me to have some shared source
files as well as some source files that are not shared, without having to change
filenames. With file linking, two materially-different versions of the same source
file having the same filename can live in two different project folders, but can't live in
the same folder shared by two projects.
Here's how I've done multiple projects targeting multiple releases:
MyProject < solution folder
MyProject17 < R17-specific project and source files
MyProject18 < R18-specific project and source files
MYProject19 ....
Common < Source files shared by all projects, added as link to each
The Common folder contains all source files that are shared by all
projects, and do not require changes. If at some point, I need to
fork one or more of those files, they come out of the Common folder
and get copied to each project folder, and added to each project.
Aside from that, there isn't really much difference between copying
projects and adding files as links, and hence, not much else to debate
about it.
-
Copying a solution is a good way.
Sorry, I don't agree.
I don't think you can maintain a version for AutoCAD 2012 and one for 2013 with just adding source files as link.
I don't believe I ever suggested that you could solve the problem that easily.
You will always have 'forks' that require release-specific code.
That's why linking and keeping common/shared source files separate from all
projects and release-specific code in each project is a better way to organize
multiple release-specific projects.
-
Tony, I want to make sure I understand this. I use a similar folder structure to yours for my C++ projects (I usually put common files into the parent folder of the folders containing the version-specific project files rather than a shared sibling, but I think the effect is the same). In a C++ project, I can add "existing items" from any folder - even unrelated folders - without any copying or "linking" involved.
Am I correct in my understanding that "Add as Link" does exactly the same thing for C#/VB.NET projects that "Add" does in a C++ project? I'm curious why "Add as Link" is not the default when adding existing items to a C#/VB.NET project, and I wonder if there's any way to make it the default. In any case, it's good to know that the option exists.
-
Tony, I want to make sure I understand this. I use a similar folder structure to yours for my C++ projects (I usually put common files into the parent folder of the folders containing the version-specific project files rather than a shared sibling, but I think the effect is the same). In a C++ project, I can add "existing items" from any folder - even unrelated folders - without any copying or "linking" involved.
Am I correct in my understanding that "Add as Link" does exactly the same thing for C#/VB.NET projects that "Add" does in a C++ project? I'm curious why "Add as Link" is not the default when adding existing items to a C#/VB.NET project, and I wonder if there's any way to make it the default. In any case, it's good to know that the option exists.
Hi Owen.
I've not used these in C++, I usually just copy source files into the project folder, so I don't know if it works the same. In C#, if you just add a file to a project and the file you're adding is outside the project folder, the file is Copied to the project folder.
-
...
Sorry, I don't agree.
For the question in the first post it is a good option to copy the solution. Maybe not the only option, maybe not the best, but it is a good option. That is what I meant.
...
I don't believe I ever suggested that you could solve the problem that easily.
I did not say you said this, but you gave that as an answer on the question in the OP. So I just gave my opinion about this process. A later post of you with the explaination of maps structure and shared files is a good example of what you propably meant in your first post. It makes much more sense and indeed it shows a solution to have version dependent solutions with version dependent and version independent shared source.
-
Here is a link to a translated article that shows you how to manage simultaneously may versions of AutoCAD sharing the same files using linked documents. It also points out that you will inevitably enter in collision with differences between the ways you write your instructions in one solution and another and how conditional compilation symbols come to the rescue (#if, #elif, #else, and #endif directives).
http://translate.google.ca/translate?sl=fr&tl=en&js=n&prev=_t&hl=fr&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.cadnovation.com%2Farticles%2F2012-04-15_migration_dotnet_2013%2Fmigration_de_solution_dotnet_pour_autocad_2013.htm&act=url
-
Here is a link to a translated article that shows you how to manage simultaneously may versions of AutoCAD sharing the same files using linked documents. It also points out that you will inevitably enter in collision with differences between the ways you write your instructions in one solution and another and how conditional compilation symbols come to the rescue (#if, #elif, #else, and #endif directives).
Here is a link to an article showing that conditional compilation symbols are not always the best way to solve a problem like this, and can only serve to needlessly complicate source code to the point where it is unreadable:
http://www.theswamp.org/index.php?topic=41868.msg470080#msg470080
-
I have yet to try it but this might be handy for maintaining multiple projects using the same source code: http://msdn.microsoft.com/en-us/library/ff648745.aspx (http://msdn.microsoft.com/en-us/library/ff648745.aspx) - Project Linker: Synchronization Tool on MSDN.
The Visual Studio Gallery page is at http://visualstudiogallery.msdn.microsoft.com/5e730577-d11c-4f2e-8e2b-cbb87f76c044 (http://visualstudiogallery.msdn.microsoft.com/5e730577-d11c-4f2e-8e2b-cbb87f76c044) for downloading. I noticed in the Q&A that there may be an easy way to get it running in VS 2012 RC
This extension was made specifically for WPF / Silverlight project code sharing so things like XAML files may misbehave.
Caveat emptor !
... Edit ... This StackOverflow answer about modifying a project file to compile other sources using wildcards is also interesting (and more lightweight) http://stackoverflow.com/a/9563860/492 (http://stackoverflow.com/a/9563860/492)
... Edit ... Thanks for clarifying Jeff. It was pretty late at night (for me) when I added that. :)
-
... Edit ... This StackOverflow answer about modifying a project file to compile other sources using wildcards is also interesting (and more lightweight) http://stackoverflow.com/a/9563860/492 (http://stackoverflow.com/a/9563860/492)
'Add as Link' already mentioned in 2nd reply here (http://www.theswamp.org/index.php?topic=41850.msg469679#msg469679), adds the same thing to the .csproj file.
-
Firstly: I'm in the middle of trying this, so treat it as an incomplete work in progress.
'Add as Link' already mentioned in 2nd reply here (http://www.theswamp.org/index.php?topic=41850.msg469679#msg469679), adds the same thing to the .csproj file.
The wildcards answer (http://stackoverflow.com/a/9563860/492 (http://stackoverflow.com/a/9563860/492)) I linked to previously automatically adds and removes all source files to/from the target project so you don't miss them. Note if you want to miss a specific file or more than you can name them using "Exclude".
<ItemGroup>
<Compile Include="..\_Src\**\*.cs" Exclude = "..\_Src\Properties\AssemblyInfo.cs">
<Link>Src\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
</ItemGroup>
This shows up in the target solution under a folder named "Src". To show the files in the root of the target project you just use ...
<ItemGroup>
<Compile Include="..\_Src\**\*.cs" Exclude = "..\_Src\Properties\AssemblyInfo.cs">
<Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
</ItemGroup>
More info on this at http://msdn.microsoft.com/en-us/library/ms164283(v=vs.90).aspx (http://msdn.microsoft.com/en-us/library/ms164283(v=vs.90).aspx) & http://msdn.microsoft.com/en-us/library/ms171453(v=vs.100).aspx (http://msdn.microsoft.com/en-us/library/ms171453(v=vs.100).aspx) & http://msdn.microsoft.com/en-us/library/ms171454(v=vs.100).aspx.
This works in both VS2012RC & VS2010sp1 although I had to close & re-open the solution in both for any file additions or deletions in the _Src project to propagate into the linked project(s).
I am creating projects for the various versions (generally milestone versions like 2006, 07, 10 & 13) which have the relevant references to their DLLs, and a separate project called "_Src", which has a reference to 2007 because it has the leanest feature set, for the actually source code that is used by all of the other projects when they build.
I don't want to build the _Src project. How do I stop that?:
- Right-click the solution Root node in the Solution Explorer,
- go to configuration properties -> Configuration.
- Change the configuration dropdown (top left on VS2012) to "All Configurations",
- then untick the build checkbox for the source project.
I am trying this in both VS2010sp1 & VS2012RC at the same time (different computers) and so far, so good. My real goal is to also share the _Src code with a stand-alone app using the ODA Teigha.NET (classic) library. Yeah, because my life is not already complicated enough.
There are various other things to watch for like target framework, x86/x64 (I got a build warning on v2007 for this but it usually doesn't matter AFAIK), changing method names (I'll use Tony's extension methods for this), a universale AssemblyInfo etc. I'll update as I crash into other things. As I said, it's a work in progress. Any input is most welcome.
cheers
Ewen
Update - this is the latest rendition of my XML to specify what is compiled in the project that references the source code:
<ItemGroup>
<!-- -->
<!--This is where to include / exclude source code files-->
<Compile Include="..\_Src\**\*.*" Exclude="..\_Src\Properties\AssemblyInfo.cs;..\_Src\bin\**\*.*;..\_Src\obj\**\*.*;..\_Src\**\*.csproj;..\_Src\**\*.user;..\_Src\**\*.vstemplate;..\_Src\readme.txt;..\_Src\**\*.lsp;..\_Src\**\*.scr">
<Link>Src\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>
The source project has an AssemblyInfoForAllProjects.cs and each project has an AssemblyInfo.cs with just the AssemblyTitle, AssemblyDescription & COM GUID in it. The rest of the info, common to every project inthe solution, lives in AssemblyInfoForAllProjects.cs