I am creating a new ASP.NET MVC Web Application in C# using Visual Studio 2010. We haven't decided on the name of our project so are using an arbitrary name for the moment to allow us to get stuck into development. Meanwhile, a brand and new name is being developed so in a month or so this arbitrary name will be redundant.
The question is, once the new project name comes into play do we continue development using the old name or is there an easy way to switch to the new name, changing the namespace and project name etc? I guess this can be done by a finding and replacing etc but wondered if there was a more formal way of doing this?
Out of interest, does anyone know how this works in companies with large development teams? For instance with Microsoft we hear of projects in development months before the release date and they often change name just before release. Presumably they don't work with this name during the entire development period.
Not a completely typical programming question, sorry if its in the wrong place.
Thanks,
Michael
I don't know any nice way beside ctrl+H
Yet sometimes adding two projects under the same solution is acceptable.
Just adding using/import at the relevant places - and it should work.
I know that the two projects should be quiet distinct to make this solution good - but it worth a second of thinking of.
If you find a decent way - please share... we all suffered from missing spots in the ctrl+h method :)
in my thinking it is possible to rename the project for doing that you can use the property to change the name of project you want.
open the project going to project property change the name their. the namespace change after next compile. maybe you need to delete the dll component from the bin..
the next thing is that visual studio never forget old name of your project for changing them rename the sln or sui project setting file then next time you can see the name [new] in title bar.
i hope this is not a big task for rename.
Another important thing to remember is to remove the old dll from your web site if you are not wiping out the existing site when you publish. If you don't do this, you may get a cryptic 500.0 error. It turns out that unless your routing specifies namespaces, you can end up with conflicting routes because of the old dll left in the bin folder.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
We have some legacy Classic ASP websites to maintain, and are wanting to use VS2010 to edit them, due to familiarity because of lots of .Net work.
I can open the website inside Visual Studio.
I can configure IIS to run the website based on the working folder used in VS2010.
I can configure VS2010 to automatically open my default browser pointing to the correct location, using the 'Base Url' setting in the Properties page.
What I CAN'T do, is work out where VS2010 stores this value, as there's no mention of it in the solution file that VS2010 has created, and as there's no project file for the website, there's nothing there too. Yet, when I close and re-open VS2010, it somehow retains this information.
This is important to me, as I need to be able to commit all files to our source control for use by other developers and, ideally, not have them worry about setting this value themselves.
So, the question is: Where does Visual Studio 2010 store the Base Url when working on Classic ASP websites?
I don't know where this is saved, but in tracking things like this down in the past I typically take the following approach:
Open Visual Studio and change this one setting
Apply the changes
Look for all files that have been modified in the last 1 minute in the project folders and in the Visual Studio folders
You can be sure there will be at least a few other files changed that are not relate to this, but it should narrow your search. You may want to re-close VS before searching too, but that will modify other files as well (making for a slightly larger pile of changed files to sift through).
If you still don't have it, search the registry (but I cannot imagine this would be where it was storing anything project specific).
EDIT:
Just created a new project and played with setting this property. It is definitely stored in the .suo (Solution User Options) file for the project, in the root of the project folder as #Lankymart suggested (and is a hidden file if you are not seeing it). It is not stored in plain-text.
You may be able to access it programmatically here: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivspersistsolutionopts.loaduseroptions.aspx
As there are a ton of absolute path settings in these files, moving it to other environments is not really an option. I would suggest you are stuck with project start up documentation that lists these settings as part of the project setup process. I think any other solution is going to be equally annoying|fragile (or worse).
Not sure if there is another way to accomplish what setting the base URL does without managing from the Start Options panel - that is likely your last-best hope for a solution.
I'm working on a website at the moment that has three separate "area's" to it. Firstly, there's the main website, then there is a User control panel, and finally an Admin Control Panel.
At the moment, I am working with three separate solutions which is less than ideal, as I can imagine updating this in the future will become rather messy.
What I would like to do ideally, is create a solution, and then include the three separate projects within that solution. I don't have a problem doing that, what I can't seem to figure out however is the publishing side of things.
I've searched around and been unable to find a solid answer to my question, which is:
If I am using multiple projects in one solution, can each one be published to a separate FTP Server Directory? -- I would also welcome any ideas on how this could be done better.
My apologies if this question has been asked before, but during my searching I have been unable to find anything that relates to this situation.
Thanks in advance,
Dave
This is definitely possible, since publishing occurs at a project level rather than at a solution level. What I like to do is go to Tools->Customize->Keyboard... and set a custom key binding for "Build.PublishSelection". Whichever project you have highlighted in your Solution Explorer will be published when you push the key binding. You can save multiple publish configurations in the publish dialog as well.
I have a website solution which contains a project with domain classes.
I have added a public auto property (get; set;) to one of the domain classes. A page on the website references this property - it was added to the page using IntelliSense.
The website project builds okay. But when I build the solution, I get the old 'Class does not contain a definition for Property' error. However, if I right click on the property in the aspx.cs file, it takes me right to the declaration in the domain class.
The other website project in the solution can call this property of the class without errors.
Actually using the website fails with the same exception.
Seems like Visual Studio is having some kind of weird episode here.
Any suggestions what might be going wrong?
Thanks
David
Edit: Here are some further observations in a series of steps.
Clean Solution (says 14 succeeded; there are 16 projects in the solution)
Build Solution (says 16 succeeded)
Rebuild Solution (fails as described)
Build Solution (fails as described)
At no point does the website actually work - it always gives the error.
It does appear to precompile successfully.
Edit 2:
I have removed the project reference and re-added it, but the problem remains.
Edit 3:
I have added a new webiste project to the solution and copied all the files across from the existing website to the new website. The problem exists in the new website as well as the existing one.
You might try using System.IO.FileSystemWatcher or one of the SysInternals tools to try to find out if the compiler is accessing an old, cached copy of your assembly somewhere.
Perhaps a reset of IIS or the Application Pools helps a bit?
Also, if the assembly is registered in the GAC, perhaps removing it and installing it back again might help.
Double check the Build Order and/or Dependencies on the project that is having difficulty finding the property. That project should require that the other project(s) build first.
Okay, the problem was that the class I was using (which reportedly didn't contain the particular property) is called Case. Despite C#'s supposed case sensitivity, presumably it somehow clashed with the reserved word 'case', and this caused the problem during compilation.
Fully qualifying the class name fixed the problem, but I think I might just rename the class 'ProbateCase'.
I have to say this is clearly a bug in Visual Studio's compilation process. Not only should 'Case' not equal 'case' in c#, but also the class has existed in my solution for about a year and a half and this problem has never arisen before. Other projects can freely use the class without qualifying its name.
Grumble over. Life goes on.
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.