I have two web projects, both these projects share client-side JavaScript currently residing as almost identical copies in both projects. I say almost because I'm clearly having versioning problems with these files.
I've managed to put the files in a solution folder and created links to them from my projects and this works when I publish the projects. However, when I run the WebDev server locally these files are not hard file system links? They seem to be maintained within the Visual Studio project as a reference only.
The problem is that the WebDev server will make a request to the presumable valid location of the file but it will not find it there because it doesn't exist as a physical file at that location.
Anyone know how to work around this?
If you use SVN, you could have the files managed as externals. Basically this will allow you to have the shared files maintained in one location, and have an external (physical file) reference to them.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Dave the Ninja
Here is a post that can help you :
Using Linked Files with Web Application Projects
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx
Related
Quite a simple one I think, but hopefully someone can help out.
I have a project in My Documents\Visual Studio 2010\Projects called EvalServiceLibrary. I build this into a project and then added it as a DLL to a web site, in My Documents\Visual Studio 2010\Projects.
So my solution as a whole contains two projects. The dll project and the web site which contains the DLL. This solution I guess holds the paths of those two projects.
What I want is to be able to send the entire solution to someone without it complaining about not being able to find various paths and whatever. I'm not sure what the best way to do this is.
Thanks for the help.
You are right that the solution contains the paths to your projects. You could edit your solution file in Notepad to change these paths.
Normally when you create a solution file the projects have the parent folder so you can use relative paths. What you could do is remove EvalServiceLibrary from your Web Project solution, then move the EvalServiceLibrary to a child folder of your Web Project solution and then readd it the project file to the solution.
Then you should have a relative path so you could ZIP the whole folder and send that to your colleague.
I recently upgraded from VS 2003 where I was working on a ASP.NET 2.0 website to VS 2010 where I have migrated to ASP.NET 4.0. So far it has been a big headache to get my site compiling with the new version. One problem was that my aspx.cs pages could not find the shared code libraries in my project. I solved this by moving my shared code to the App_Code folder (if there's a different/better way to do it please let me know).
Another issue that I am finding confusing is with pre-compilation. With VS 2003 I could click the build project button and it would precompile my site into a myweb.dll and myweb.pdb files. Now I'm having trouble doing the same in VS 2010. When I build the site in VS 2010 the dll is not created. I did manage to find an option to "Publish" the site which takes forever (like 2 minutes) and involves duplicating the site to another folder. This would have been acceptable but instead of making the single DLL file, it makes a bunch of files: App_code.compiled, app_code.dll, App_code.pdb, App_global.asax.compiled, App_global.asax.dll, App_global.asax.pdb, App_Web_lrpcway1.dll, App_Web_lrpcway1.compiled, App_Web_lrpcway1.pdb.
The application works - I can deploy it with all these files. However, I'd really like someone to explain what are the extra files and if there is a better way how to do it.
Thanks
This is the difference between a website and a web application.
You can convert your website to a web application to have it
behave more like you are used to.
The files in appCode are compiled when required to run and thus
does not provide dll.s in the bin/debug folder, but they should
be created when the application actually runs (but it is not
put in the same location).
Here is a nice write up about it Link
You can use the ASP.NET Merge Tool to combine all of the little DLLs into one big one.
http://msdn.microsoft.com/en-us/library/bb397866.aspx
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.
With Visual Studio (2008), is it possible to load a project (to a solution) that exists on a remote location ?
Basically what I want to do is somehow "host" a VS Project online and then load this project to a solution from a remote location. Is this possible in some way?
This is so that I can keep integrity when loading my Utils Library (used in tons of projects) and I don't want copies of my project in different projects and all having different versions etc...
I know that a possible solution is to have the Utils Library project hosted in SVN and then the folder would sync to it directly, but is there any other way to do this (ie, something more direct) ?
Yes, if you can map a network drive to it, the you can open the files from the location in visual studio.
you can map network drives to ftp servers by entering "ftp://your-ftp-server" in the path box.
Like others have said though, it's not really recommended. VS reads/writes a lot more than just to edit the main project files, it does all kinds of other stuff, so your network traffic be higher than you really want.
Or you could look at dropbox. It comes with a explorer addin that keeps your local PC in sync with the server.
My recommendation would be to use source control like subversion though.
It is possible, but not recommended (you'd be better using some form of source control, be it SVN, or a shared source provider like Codeplex (for open source projects) or TFS Preview (for closed source projects)
Is it not simpler just to have the compiled dll referenced in each solution? The way you are proposing is going to open you to changes to the project for one solution causing problems in a bunch of other solutions, that you might not immediately see.
Better to have a version of the Utils dll referenced in each sub solution and you can then update that dll when necessary, and test at the same time.
Our ASP.NET web shop is starting to move from VisualSourceSafe to Subversion (VisualSVN/TortoiseSVN).
Subversion needs to have all files residing in a single directory tree. This is simple when using a Web Application Projects - everything lives in
\Visual Studio 2008\Projects\MyProject
With a Web Deployment Project, though, it's a bit of a mess. You have
\Visual Studio 2008\Website\MyProject for the website itself
\Visual Studio 2008\Projects\MyProject for the solution file
\Visual Studio 2008\Projects\MyProject\MyProject_deploy containing a complete "deployment" version of the website
What's the best practice for managing this in SVN? Should I just move the website under \Visual Studio 2008\Projects\MyProject and add the whole thing to the repository, including the deployment version of the site?
Best practice is to leave your solution file at the root of your project structure, with every project in a sub-folder. That way, each project can be checked out individually without the solution file if people wish to do so.
So in your case, you should have, in your SVN repository, something like:
svn://{repository_root}/MyProject/Website/ {all website files including the .proj file}
svn://{repository_root}/MyProject/WebsiteDeployment/ { all deployment files including .proj file}
svn://{repository_root}/MyProject/MyProject.sln
So the answer to your question is yes, you should move everything under a folder called "MyProject".
Edit: you should also consider having MyProject/Trunk, MyProject/Tags, and MyProject/Branches, which is considered best practice according to the SVN Manual.