I'm trying to publish files that are unrelated to the solution as part of a one-click publish job.
This would be relatively standard, similar to what is outlined here and here too.
However, the files themselves need to reside one folder above the actual root of the website.
If I try to specify a relative path outside of the website directory, such as <DestinationRelativePath>..\Data\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> this just results in the publish skipping the item, since it claims it is up to date (in reality there isn't anything there so it can't be up to date).
I've had a quick look and can't find a way to specify an absolute path, is this something that would be possible, or is there a better approach to take here?
As part of the properties of the file you want to copy you can set it to be "Copy Always" this could resolve the issue if it is just a date issue.
Related
Somehow my solution and project differ as to their Path/FullPath.
The Path property of my solution ("customerreportingnet") is:
C:\Users\cshannon\Documents\Visual Studio 2013\Projects\customerreportingnet\customerreportingnet.sln
The only project beneath that solution is a Website ("http://localhost/EMS/customerreportingnet/").
The website project's FullPath is this:
C:\EnhancedMonthlySalesReporting\customerreportingnet\customerreportingnet
Why would the solution and project location differ?
Did I do something wrong in the setup? I downloaded the files from a .zip file, and extracted them to C:\EnhancedMonthlySalesReporting\
I then created a Virtual Directory in IIS, mapped it to C:\EnhancedMonthlySalesReporting\customerreportingnet\customerreportingnet, giving it the Alias "EMS".
Then in VS I open the website (solution/project) this way:
File > Open Website...
and then I open IIS > EMS
When I do this, I do not see any files beneath the "project" - all that's visible in the Solution Explorer are just the solution and project names - no subfolders or files beneath them. But when I right-click the solution "customerreportingnet" and select "Open Web Site", then reply OK to "Open the Web site (this will close the current solution)" all is relatively well - I can right-click the project ("http://localhost/EMS/customerreportingnet/"), select View in Browser (Internet Explorer) and the site runs.
The only files in C:\Users\cshannon\Documents\Visual Studio 2013\Projects\customerreportingnet\ are:
customerreportingnet.sln
customerreportingnet.v12.suo
C:\EnhancedMonthlySalesReporting\customerreportingnet\customerreportingnet has those files and many more (as well as beaucoup folders).
Should I try to reset the solution Path to C:\EnhancedMonthlySalesReporting\customerreportingnet\customerreportingnet, or is that just an oddity, but not a problem?
If so, is that as easy as just changing that property value, or will that mess things up?
Is it a bad idea for my solution and project to be stored in separate
locations?
A solution is a "container" for projects. Where they are in your local file system doesn't really matter. So in that context, it's "fine".
It's not unusual to have some solution context that is composed of some "projects you did before". So you can "organize" a "new" solution composed of projects located elsewhere (from some other "solution") along with new items.
However, once you get into Source Control, whether it's TFS or GIT, then it will matter - they (projects in a solution) have to be in the same parent folder to be handled easily. So in that context, it's "bad".
TLDR; there are still ways to effectively source control "projects in different folders" - each one is it's own separate "repository". But you'll have to manually/separately do your syncing, merging, etc.
If I'm following your post correctly, I think what you're looking for is Add..., not Open... - you want to add an existing project or web site to a Solution.
Depending on what you're after, and what files you're dealing with:
if you have a Project in the zipped file, then you can Add Existing Project, and so on...
Unsure why you needed to do what you did in IIS - you can do debugging within Visual Studio (IIS Express).
Alternatively, you can Publish your web site/application from Visual Studio and target a local file system folder that you can then set in IIS (Local IIS if installed) - this way, you sort of have a "dev" (VS) and "staging" (publish folder mapped in IIS) environment in your local machine.
Hth...
After you extracted your code and opened the project in visual studio.
Visual studio will automatically create a solution file if you open a project (you can also open a solution file directly). Once you click save all or save your solution file it will save it to the previous location or to the default location.
Since you did not save the file before, visual studio will save it to the default location:
C:\Users\cshannon\Documents\Visual Studio 2013\Projects\[ProjName]\[ProjName].sln
If you want other developers to be easily able to open your project. (especially when you start to have multiple projects inside 1 solution), you want to include the solution file inside the project location. Otherwise every developer has to create this solution file himself, which is annoying and cumbersome work.
Since dotnet core the best practice file structure is this:
/root
/src <== contians all the projects per folder
/project1
/project1.csproj
/etc*
/project2
/[ANameForSolution].sln (so directly inside the proj folder, next to src)
The old habit people use was more flat:
/root
/project1
/project2
/YourSolution.sln
The best practice, moving everything to /src is because lately a root of the project already has a lot of (config) files, and this way you can keep the root a bit cleaner.
I currently have a solution which recently added a new website to the TFS source control. Due to a mistake during creation, the website physical directory is like below:
Z:\Projects\NewWebSite\NewWebSite
Instead, it should be like below:
Z:\Projects\NewWebSite\
The problem I had was when trying to remove and add the website with the new physical path into the solution. Every time I do so, for some reason it will automatically refers to the first path. If I tried to remove the folder, it will give me an error saying it can't open the path since the folder no longer exists.
My solution is to basically unbind everything and create a new solution from scratch, then re-adding the website to the solution. My worry is that I am just working around the problem, and that it is still present somewhere in TFS, waiting to mess up someone else's solution when they check out.
So, does anyone knows what is causing this, and what is the best way to fix this sort of behavior?
If your solution name is the same as your project name then that is the default structure. When making a new project, start by creating the solution with a unique name and then adding your project to that.
No matter what, you do actually want that structure. Its like that for the purpose of expandability. If you need to add additional projects or maybe separate your operations into different projects (like Data vs Web for instance), the Solution/Project folder setup will accommodate.
In other words, don't fight it. Just make your solution name unique from your Web application name to make it less ugly looking.
TFS doesn't deal with physical locations at all. This is handled by your TFS client, when you map a workspace a physical path. This is not something that TFS deals with.
As such, i'm confused by your comments.
i'm trying to package a deployment for Azure, but it is not packaging some files that are needed for the app to work properly. Those files are mostly PDFs and DOCXs.
If I go to the Package/Publish settings I have 3 options:
1. Only files needed to run this application. This is the default option which is excluding the PDFs and DOCXs.
2. All files in this project. This is including the missing files, but it is also including the code behind files (even though they are compiled). I do not want to include those files.
3. All files in this project folder. Haven't even tried this one because it will probably be worse than option 2.
My question is how do I set which extensions are actually needed to run this application?
Right after posting this question, I figured it out. For any out there with the same or similar problem here it goes...
In order to include certain files in the deployment package you have to set build action of those files to Content. Just right click on the file in solution explorer and click Properties. There change the Build Action to Content:
Also, you have to set the the setting of the Package/Publish to "Only files needed to run this application". The default option.
Using a Visual Studio 2010 ASP.net web application, I have several projects that share some JavaScript/css files. The most logical way for them to share these files is to place the files in a single folder and each project has them included with the "Add as Link" option. However, if I add the files this way when I'm debugging using either the Visual Studio Development server or debugging using a local IIS web server all requests for these files return 404 Not Found errors. If I publish the site then the files are copied but that obviously doesn't help with debugging.
Is there something I'm missing or is this a failing on VS's part?
To overcome this problem some time ago I created a 'MSBuild.WebApplication.CopyContentLinkedFiles' nuget package. This package adds MsBuild target which copies all content files added as link to project folder during build.
Note: if you use source control then it is better to add copied files (from Web Application folder) to ignore list.
I wouldn't really call that a failing, since you asked for that behavior in the first place: linked items in Visual Studio projects are actual links to external files. Those files can reside anywhere on the disk and are not copied into the project folder.
You might want to copy those files locally yourself during a pre-build event. That way, the files will remain synchronized and you won't duplicate them until your first compile.
The problem seems to be that the website runs right from your source folders, rather than from the bin folder. This means that the file will be missing, whether or not it is copied to the output folder.
It's probable that running from a local or remote web server would not have this problem, though I didn't get that working, and I'd rather not add IIS to my local machine if I don't have to.
Adding a pre-build copy command did work. Note that the current directory will be the bin folder. (You can use cd to echo the current directory to the build window if you want to see it):
If the file is in another solution, your command will look something like (three ..s: one to get out of each of bin, project, and solution folders):
copy ..\..\..\OtherSolution\OtherProject\Scripts\MyJSFile.js ..\Scripts\
If it's in the same solution, but a different project:
copy ..\..\OtherProject\Scripts\MyJSFile.js ..\Scripts
One minor issue is that the link to the file will collide with the new copy of the file, even if you don't add it to your project. As long as you make the link first, it seems to work. If you copied the file first, you'll have to manually delete the copy, and then refresh the solution explorer before before being able to add the link.
Select the link in Solution Explorer and then look at properties window and set Copy To Output Directory to Copy Always. Linked items are set to Do Not Copy by default.
BTW, you can copy many files as links very easily directly from Solution Explorer when using VSCommands 2010 extension.
See this blog post about a simple addition to your project file.
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
We're a small team starting to use TortiseSVN to manage our web projects.
I was just wondering what is the best way to manage web projects into Subversion.
As you know a web solution consists of the .sln file as well as all the .aspx files.
Well we noticed when we right click the solution and we select "Add selected projects to subversion". It prompts me to tell it where to store the .sln file. So I give it some path like svn://serverName/CIS/MyWebSiteProject. Cool it just placed the .sln file...so I thought to myself how is it going to store the .aspx files as well.
Within a second I got a second prompt, I thought cool it is prompting me for the .aspx pages. So I tried giving it the path svn://serverName/CIS/MyWebSiteProject/ASPX_Files, but it comes back with an error stating I cannot place this folder within this path. I actually have to go outside of the folder MyWebSiteProject.
Not good cause now I have 2 folders one with the .sln folder and the other with all the .aspx pages and these folders are sitting on:
(sln file):
svn://serverName/CIS/MyWebSiteProject
(aspx files):
svn://serverName/cis/myWebSitePages
This really is not ideal cause I am sitting on the root of CIS with 2 folders for really one solution. Now when I try to check the project out I have to check both folders out.
What makes this even worse is when I do check them out I try to open the .sln file and I get an error that it cannot find the corresponding .aspx files. This seems like too much work, is there an easier way or a recommended way of using tortisesvn/subversion with asp.net web projects ?
While I am sure you have TortoiseSVN installed, it sounds like you are using Ahnk or some other VS SCC plugin to add from within VS.
I would suggest not using the plugin to initally add the solution to SVN, but to use TortoiseSVN in Windows Explorer for your initial check in. This will add your solution directory in its original state.
From that point on, you should be able to use the SCC plugin from within VS without trouble.
EDIT
Ok, after your commment I realize that I was not fully understanding the problem.
If you are dealing with a single project, after you create your solution and project, select the solution in Solution Explorer, go to 'file>save solution as' and save the solution inside the directory where your project file is.
Close the solution and go out to Explorer and use Tortoise to add the directory to SVN. If you have multiple projects/sites, just pick one to hold the solution.
Does that make sense? and from that point you should have no problems with ahnk
The key to successfully using Visual Studio with any source control is to put the solution file in the same path as the rest of the project files.
Usually, I will do something like the following:
\Project\Project.sln
\Project\MainWebSite\*.* <-- All web site files (including .??proj here).
\Project\Library\*.*
Then, I manually put \Project\*.* into source control.
Other options exist, as for my recent projects, I have been using:
\Project\SolutionFiles\Project.sln
\Project\MainWebSite\*.*
\Project\Library\*.*
Again, I manually put \Project\*.* into source control.
I generally find that it is better to set up the repositories for my solutions and projects from within Tortoise SVN. Then use whatever VS plugin that you care for to manage the commits of your pages etc. This gives you a little more control and allows you to get your setup correct from the start.