How to restructure a solution that is currently being maintained by source control? I need to create a couple of folders and move the existing projects to folder and another folder to maintain dependencies etc..
so, shall I make the changes in source control itself? or from my local machine? I am facing it difficult to make changes locally (where I mapped the project to source control) and sync (check-in) the changes as the structure itself is completely get modified.
So I am thinking the changes has to be made at source control? Pl suggest me.
It is easier to do this in TFS for a few reasons:
You will create a historical change set of what was moved or renamed, vs. doing locally you will be forced to do adds/deletes
TFS will automatically move the folders on your machine and update the mapped paths.
If you also need to rename anything (which you didnt mention, but it can be considered part of code organization), TFS also updates solution files appropriately when you rename projects, so you don't have to remove and re-add projects to your solution that includes renamed projects.
The only note is that often you will have files and folders such as bin and obj folders that are not in TFS, and those will not get moved by TFS, leaving half empty directories. You will need to clean those up manually on your machine.
Related
I have two different projects sharing same SQLite database(One is Web-api, Other one is WPF App). However, the database is located in (let's say project A). In the project B, I used "Add as link" to copy the DB to project B.
I have three questions
If the DB in project A changes, the linked DB also changes. However, if i change the DB in project B, does the original DB change?
Is there any better way to do this?
Will it still work if i release the solution.
original DB
copied DB
properties of copied DB
A local database like a sqllite file should be installed to appdata.
This is user specific by default, but there's also a public user you could use.
It's up to your installer - and that means you - to put it there.
If this file is to be shared by two apps.
You would need to configure whatever you're using as an installer to write to a common location in appdata. That should be under public if multiple users need to share the file.
By default, if you add a file as content and copy if newer that will end up in your bin when you develop and it will work for you. When you install, if you install to program files the sdf will end up in there as well and your user will not be able to write to it.
There's a more complete explanation of appdata files here:
https://social.technet.microsoft.com/wiki/contents/articles/30915.c-local-files.aspx
In the Resources folder of my project, I have many different DLLs from other assemblies in my solution. These DLLs are used as embedded resources so I can have a single EXE without having to have local copies of all the DLLs. What I want to be able to do is have them updated every time I build my entire solution. So for example, if I have AssemblyOne/bin/x86/Debug/Foo.dll, I want the DLL to always copy over to LocalAssembly/Resources/Foo.dll whenever I build the project.
Is there an easy way to do this? I was looking at the post-build-event macros, but none of them would be able to directly reference my "LocalAssembly", which is not the Solution Directory. Also, I'm not sure how I would go about writing a new custom post-build command in a way that the newly copied DLLs would not be an absolute reference to my local machine. Thanks! Please comment for more information and I will edit the question.
You need not access only your solution folder in post build events. The post build scripts run with whatever permissions the compiler had when it ran. Since in Visual Studio things frequently run with Administrator permissions, chances are great you have access to your entire file system. As a result, if you are wanting to copy resources around, you merely need to presume that you are starting the xcopy call in the build destination directory. From there, you can navigate around with normal paths. So if, for example, you needed go up three levels and then into the directory LocalAssemblies, your copy command would look like xcopy Foo.dll ../../../LocalAssemblies.
I have a new application i would like to deploy to a Managed Server I have recently signed up for. I would like to know what would be the best way to deploy to it. In my experience I have seen that many of the asp.net applications just push dlls to the server. How is this achieved?.
I have Tortoise SVN as my subversioning system. I have a repository on another server and usually i commit my changes and then update my release folder in the managed server but this has all the .aspx, solution and other files I belive are not needed. How can I do my set up so that I only push the dlls and when updating that only dlls are updated?.
I am not too clear on this and would like an explanation and best practices given this scenario.
I have faced similar questions before and follow the below steps every time I move the compiled files for incremental fixes in my application.
Maintain two separate copies of the solution files - Local Application and Production application
//This is very important because once you go to production environment. One copy for your local working and other copy only for deploying in the live server. This copy should be up to date with your live server copy.
Make the changes to files and compile and test the application in your local application folder/solution. Now commit only the files that you edited. SVN will take care of this. It will show you a possible "red mark" for the files which differ from the updates present in the repository. In this way you can track the pages which were modified.
Now open open your production solution folder and update the folder. This will update the files in production application folder.
Now compile and test the changes done. Verify if its issue is fixed or the changes are reflected same as the Local application copy. Now build the application and publish to a folder.
To know the modified files:
DLLs:
Go to the bin location of the folder and "order by" modified date. These are the dlls which are to be copied and replaced with in your life server.
ASPX/ASCX
a) Open SVN of production application folder. Right click and click show log. This will show all the files modified/updated with date. Select the ones last updated and note down the location.
b) Now navigate to the location in your published folder and select those files "ordered by" descending/ascending modified date of the files. Replace those files alone to your LIVE server.
Note: This is certainly not the best possible solution, but one of the general practices followed throughout the industry. There are few other plugins which can track changes and publish the relevant files to your published folder. But again ,this is applicable only if you have the source codes and application files in the same machine as of the one you are hosting the application from. Let me know if you have any question in this.
You can just use visual studio web deploy, it will automagically figure out what needs to be updated and only pushes what is necessary unless you ask it otherwise.
Sorry, a bit of a noobish question here...spent an hour on Google and in MSs help documents, my head appears to be in the wrong place, I can't figure this out.
I have a C# project set up in Visual Studio 2012 that has references to a few .dlls that I have on my own hard drive (NetOffice .dlls to be specific, for Excel Interop). I've been adding them by right clicking on my references folder, going to Add Reference and then going to Browse to find the files. At that point they are included and everything works as expected on my side.
The problem occurs when I share the project. I'm using Git to keep the project coordinated between myself and a couple team members. I'll run my commit and push it then have my teammate do his pull. Everything shows up on his computer correctly, but when we open up the project it tells me that the NetOffice .dlls are missing.
I'm guess that this is because the files are only linked locally on my computer, but I can't figure out, for the life of me, how to make the .dlls exist in the file structure so that they travel with the project when I push it.
We have a few NuGet packages we use as well, and they seem to work just fine after being transferred. I've also gone into the .dll properties for NetOffice and turned "Copy Local" to true, yet it's still not included.
All I want is to be able to link references and then send the whole thing (dlls included) to my teammate, what am I doing wrong? I figured I would want to simply include the .dlls in the project structure but... I'm just not understanding something. Any help please?
1 Create a folder in the file system at the same level as the solution file.
2 Copy the external dll's to that folder.
3 Add a Solution Folder tho the solution.
4 Add each dll to the the solution folder using add existing item
5 Reference the Dll's in the solution
The steps 3 and 4 aren't really necessary, but they help to keep things organized.
Lets assume your source control root folder is called SourceRoot
and your solution files are under a folder called JaySolutionFolder
I prefer:
Adding a new folder to your source control, under SourceRoot, called SharedDlls
Copy all external Dlls to this Folder.
Add this dll references form SharedDlls to your project.
Commit this folder
Now your teammates have to get JaySolutionFolder & SharedDlls to compile the sources.
Later this SharedDlls could be target directory of Build process (Using tools like TFS Bulid, NANT or else)
This will be a way to minimize team based development problems.
In release and software installation, you can use installers or software package builders like installshield or Visual Studio Setup Package or ... to solve external dlls problem
Hop this helps.
Although it's not good practise to include binaries in your git repository, doing so will solve your problem.
The quick fix could be to create lib directories in sensible locations within your repository (I'm not a C# developer but Gama Felix's suggestion seems correct).
Then commit these folders and push to the server.
I've created a Codeplex site for an app I'm building and right now I just right click the entire solution folder Visual C# Express created for me, and used that.
Now in my repo I have a lot files that I'm assuming will enable the user to compile my application on their end.
I heard I shouldn't upload the /obj folder and some other things.
What things are absolutely necesary for me to commit to my repository?
You should ignore the following, by setting the svn:ignore property on your project folder:
bin
obj
*.user
*.suo
You need the solution file, the C# project file(s), and all of the code files.
Basically, leave out the .suo file (with the solution), any user specific files (which will have your username appended to them, the bin\ and the obj\ folders. Everything else should be included.
It's common practice in organizations I've worked with to also include binary resources to which we don't have the source code and are required for the build in the source control. I'm aware that this is a somewhat controversial practice but it's worked wonders for us. Usually we keep them in a solution-rooted folder named 'Resources' or the like such that they're available for each developer to use when they check out the solution.
If you would use the Standard Edition of Visual Studio you could use the AnkhSVN Plug-In, but in Express this is not possible. :-(
So what you should exclude
folder obj
folder bin
file *.user
file *.ncb
Everything else has to be in your repository.