I've been publishing my site regularly without too much trouble. But today I noticed that it won't overwrite existing .cshtml razor files with the new versions. I publish, look at the folder, and see the files are still out of date. If I delete the file and then publish, it will put the new version there. But if the file already exists it won't overwrite it and my production website is out of date. I tried doing the option 'delete files before publishing' but it gives me an access error that it can't delete folders. I tried deleting the entire folder but then I lose my .svn folders and it won't recognize version control.
Is there a way to force the Publish command to overwrite my .cshtml files with the latest version? (note: the dll files get overwritten fine)
Have you set the Copy to Output Directory to Copy Always?
I use Build Action = Content too.
Seems like Read-Only attribute is set on files, so they can't be overwritten. Check VS Output window for signs of errors.
Advice: Try to NOT include generated files (this also means folder with published files) in source control. VCS tools usually tend to lock-up files they work on.
Having .svn files on Test/Prod server is also not a good idea.
Related
Using Code Gear Delphi 2007 (don't know if it matter), each time a ".bpl" package is compiled, a ".~bpl" file is created too.
What are ".~bpl" files? Are those files required or is there a way to avoid their creation?
It's the backup of the previous copy of the BPL file, just like the .~pas files are backups of the .pas files and the .~dsk file is a previous copy of your desktop settings file and the .~dfm is a previous copy of your .dfm file.
There's no way to avoid their creation, but they're harmless. I'm not sure why they would concern you, but you can always create a post-build event in your project to delete them after a successful build.
I am having an issue where when I select to publish my MVC project to the file system so I may upload it later via FTP to my Web Host, it fails complaining of missing files.
Believing that it may think these files are required to compile the project, I copy them to the locations that it expects and it resolves the error but produces yet another error about another missing file.
These files incidentally are not required to run my Web Application but were simply files used during the initial test phase of my project. More specifically, picture files.
The next step I took to resolve the issue was to Clean and rebuild the Solution and Project Entirely with all those files it was referencing in the errors removed. The Project builds successfully and runs as expected.
I then attempt to publish to the file system and again it complains of those files as if its getting that information from somewhere other than obvious places within my Project.
I have deleted the object directory content, cleaned and rebuilt; again it references these files that don't exist anywhere within my Solution.
So my question is, Where exactly does the Web Publishing Wizard get the information it uses to copy the required files to the Target Location? I've checked the .pubxml file but there's nothing in there that would provide the information.
For instance, if I'd initially built my site using reference to a .png file then later use a .jpg file. The Wizard seems to be getting the metadata for the initial build somewhere and insists on inclusion of the .png file when it is no longer needed.
I believe I have Upgraded to the latest build and patches for VS2012. I am Currently running version 11.0.50727.1 and using .NET 4.5
I cannot find any relevant information on this problem so it may be a quirk in my Environment so I'm searching for some feedback.
If no answer can be provided, if I could simply know what folders and files are required to deploy an MVC site; I'll perform the deploy manually and trash the Wizard concept. I just thought it would be the most appropriate way to deploy but if its going to be a pain; I don't need it.
This is the Error:
Error : Copying file <relative path>\image.png to obj\Release\Package\PackageTmp\<relative path>\image.png failed.
Could not find file '<relative path>\image.png'.
The new file that replaced the old file is actually image.jpg and its in there. I could alleviate this error by copying the old file back to its initial location, but why should I if its no longer required?
In case the question wasn't clear. I have 3 MVC projects in one Solution. Every time I create a new project it adds the "Scripts" folder with all the .js files I'll ever need. I don't want to have this created every time for every application. Is there a way to reference scripts from a central folder in the solution so all applications/projects can share one common script folder with all the scripts common among them?
Edit:
Please explain the pros and cons of doing this if there are any...now I'm curious.
Here is what I would recommend:
Right click the solution and create a New Solution Folder called Common Javascript Files (or whatever you feel like calling it.
Right click on the Solution, click Open Folder in Windows Explorer,
or navigate there manually for other versions of Visual Studio :(
In the solution directory, create a directory with the same name as the solution folder (solution folders do not normally match directories at the source code level but this will for sanity sake).
In this new directory, add files that need to be shared between solutions.
In Visual Studio, click the solution folder and select Add - Existing Item.
In the file selection dialog, navigate to the directory previous created, select the file(s) added to the directory and click Add.
In each Project that needs a shared file, right click on the project (or directory within the project) and click Add - Existing Item.
Navigate to the shared Directory, Select the files and click the drop down arrow then click Add As Link.
Now the files in the projects are essentially short cuts to the files in the Solution Folder. But they are treated as actual files in the project (this includes .CS or Visual Basic files, they will be compiled as files that actually exist in the project).
PROS
Files are truly shared across projects at Design time
Only the files needed for each project can be added, it's not all or nothing
Does not require any configuration in IIS (virtual directory etc)
If the solution is in TFS Source control, you can add the Directory to the TFS Source and the shared files will be source controlled.
Editing a file by selecting it in the Project, will edit the actual file.
Deleting a Linked file does not delete the file.
This is not limited to JS files, linked files can be ANY file you might need (Images, Css, Xml, CS, CSHTML, etc)
CONS
Each deployment gets it's own file.
There is a small learning curve when understanding that Solution Folders are not Directories that exist in a Solution Directory.
The best thing to do, imo, is to roll your own CDN... Basically just create another site in IIS and give it it's own binding, e.g. "http://cdn.somedomain.com"
Then store all of your css/js/fonts/shared images etc on the CDN site and link to them from your other sites.
Doing so solves 2 problems,
All of your stuff is shared when it needs to be and you only have to manage 1 revision per file.
Your users browsers can cache them in 1 single location instead of downloading copies of your stuff for every site that uses them..
I added this answer because I see a lot of people referrencing creating virtual directories. While that does indeed share the files, it creates multiple download paths for them which is an extreme waste of bandwidth. Why make your users download jquery.js (1 * number of sites) when you can allow them to download it once on (cdn.somedomain.com).
Also when I say waste of bandwidth, I'm not just talking about server bandwidth, I'm talking about mobile users on data plans... As an example, I hit our companies HR site (insuance etc) on my phone the other day and it consumed 25mb right out the gate, downloaded jquery and a bunch of stuff 5 times each... On a 2gb a month data plan, websites that do that really annoy me.
Here it goes, IMO the best and easiest solution, I spent a week trying to find best and easiest way which always had more cons than pros:
Resources(DLL)
Shared
images
image.png
css
shared.css
scripts
jquery.js
MvcApp1
Images
Content
Shared <- We want to get files from above dll here
...
MvcApp2
Images
Content
Shared <- We want to get files from above dll here
...
Add following to MvcApp1 -> Project -> MvcApp1 Properties -> Build events -> post build event:
start xcopy "$(SolutionDir)Resources\Shared\*" "$(SolutionDir)MvcApp1\Shared" /r /s /i /y
Here is explanation on what it does: Including Build action content files directory from referenced assembly at same level as bin directory
Do the same for MvcApp2. Now after every build fresh static files will be copied to your app and you can access files like "~/Shared/css/site.css"
If you want you can adjust the above command to copy scripts from .dll to scripts folder of every app, that way you could move some scripts to .dll without having to change any paths,here is example:
If you want to copy only scripts from Resources/Shared/scripts into MvcApp1/scripts after each build:
start xcopy "$(SolutionDir)Resources\Shared\Scripts\*" "$(SolutionDir)MvcApp1\Scripts" /r /s /i /y
This is a late answer but Microsoft has added a project type called Shared Project starting Visual Studio 2013 Update 2 that can do exactly what you wan't without having to link files.
The shared project reference shows up under the References node in the
Solution Explorer, but the code and assets in the shared project are
treated as if they were files linked into the main project.
"In previous versions of Visual Studio, you could share source code between projects by Add -> Existing Item and then choosing to Link. But this was kind of clunky and each separate source file had to be selected individually. With the move to supporting multiple disparate platforms (iOS, Android, etc), they decided to make it easier to share source between projects by adding the concept of Shared Projects."
https://blogs.msdn.microsoft.com/somasegar/2014/04/02/visual-studio-2013-update-2-rc-windows-phone-8-1-tools-shared-projects-and-universal-windows-apps/
Info from this thread:
What is the difference between a Shared Project and a Class Library in Visual Studio 2015?
https://stackoverflow.com/a/30638495/3850405
A suggestion that will allow you to debug your scripts without re-compiling the project:
Pick one "master" project (which you will use for debugging) and add the physical files to it
Use "Add As Link" feature as described in Eric's answer to add the script files to the other projects in solution
Use CopyLinkedContentFiles task on Build, as suggested in Mac's comment to copy the files over to the second over to your additional projects
This way you can modify the scripts in the "master" project without restarting the debugger, which to me makes the world of difference.
In IIS create a virtual folder pointing to the same scripts folder for each of the 3 applications. Then you'll only need to keep them in a single application. There are other alternatives, but it really depends on how your applications are structured.
Edit
A scarier idea is to use Areas. In a common area have a scripts directory with the scripts set to be compiled. Then serve them up yourself by getting them out of the dll. This might be a good idea if you foresee the common Area having more functionality later.
Most of the files that are included by default are also available via various CDN's.
If you're not adding your own custom scripts, you may not even need a scripts directory.
Microsoft's CDN for scripts: http://www.asp.net/ajaxlibrary/cdn.ashx
We have multiple config files (app.DEV.config, app.TEST.config, etc) and a pre-build event that copies the correct config file to app.config. Obviously the configuration specific files are in source control --- but at the moment so is App.Config, and that shouldn't be.
How can I mark that one file as excluded from source control, but obviously not from the project.
I'm using VS 2005, and 2005 Team Explorer.
It's easy in TFS2012, create a .tfignore file
http://msdn.microsoft.com/en-us/library/tfs/ms245454%28v=vs.110%29.aspx#tfignore
######################################
# Ignore .cpp files in the ProjA sub-folder and all its subfolders
ProjA\*.cpp
#
# Ignore .txt files in this folder
\*.txt
#
# Ignore .xml files in this folder and all its sub-folders
*.xml
#
# Ignore all files in the Temp sub-folder
\Temp
#
# Do not ignore .dll files in this folder nor in any of its sub-folders
!*.dll
# EDIT https://msdn.microsoft.com/en-us/library/ms245454(v=vs.110).aspx#tfignore
# A filespec is recursive unless prefixed by the \ character.
Select the App.config file in Solution Explorer, and choose File -> Source Control -> Exclude App.config from Source Control.
There is a checkin policy (Forbidden Patterns Policy) in the MS Power Tools which lets you screen filenames against a regular expression. See: Microsoft Team Foundation Server Power Tools
While checkin policies are not completely foolproof, they are the closest thing TFS has to enforcing user-defined rules like what you're looking for.
(And as the others have said, you can also cloak a file or folder, which means it stays in Source Control and is visible to everyone else on the team, but it's not copied to your PC until you decide to uncloak it; or you can delete the file, which means it gets deleted from everybody's PCs when they get latest - but neither of these options will prevent such files being added to source control in the first place)
There is an option that is hard to find:
1. Select the file or multiple files in Solution Explorer
2. Go to File -> Source Control -> Advanced
and here it is
Keep in mind:
If you right click a file in Solution Explorer you only find "the most important options" not all :)
If all you want is to have a file in the project but not under source control with TFS, just go into SourceControl, delete the said file, and undo your checkout of the project file (it will attempt to remove the file from the project as well). Then check-in your delete of the file you are excluding. In the solution explorer you should see that there is no source control icon next to the file you're excluding. The project file should list a file there, but that file should now no longer be under source control.
Keep in mind, any other person will now see a missing file in the project when they get latest.
TFS allows you to cloak at the folder/file level. When something is cloaked, TFS won't attempt to sync it (much like a svn:ignore).
When setting up your workspace, cloak anything you want TFS to ignore. A more detailed how-to is here.
This worked for me:
One way is to add a new or existing item to a project (e.g. right click on project, Add Existing Item or drag and drop from Windows explorer into the solution explorer), let TFS process the file(s) or folder, then undo pending changes on the item(s). TFS will unmark them as having a pending add change, and the files will sit quietly in the project and stay out of TFS.
Source:
=">How can I exclude a specific files from TFS source control
Visual Studio 2013 (and 2012)
This feature is available by selecting the file(s) and going to:
File > Source Control > Advanced > Exclude ... from Source Control
This question was asked a while ago but it pertains to the same type of issue I was having.
The Problem:
We want to check in our code.
We then want build our project.
During our build we depend on Build Events to move files around so we have the proper files in place for the build process to complete.
When our Build Event tries to copy the files, we get Access Denied errors.
The Reason:
Team Foundation Server Visual Studio Plugin changes the Read Only attribute on our files to READONLY TRUE when we check in our files.
Build Event Example:
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
Above, we simply need to move a file from our Target Build Path (the bin\debug or bin\release folders) to our Project Folder. In my situation, this was so I could include project built files in my installer. My Installer wasn't grabbing them as part of the Project Output.
The Fix: (nearly kicked my self in the face when I figured this out)
New Build Event:
attrib -R "$(ProjectDir)SomeFile.ext"
copy "$(TargetDir)SomeFile.ext" "$(ProjectDir)"
attrib +R "$(ProjectDir)SomeFile.ext"
We're all having fun with Build Events right? Above I simply do 2 things, I remove the read only attribute, now the files not read only. Copy my file as I was originally wanting to. Then replace the Read Only Attribute (optional I guess) to keep Visual Studio and Team Foundations happy.
And yes... I'm still kicking myself in the face on this one.
I have a similar issue, my App.config contained sensible data (e.g. username) that this data should not by sync with TFS.
The article Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service describes an good approach to prevent this issue:
Use the "file" attribute of the "appSettings" element to reference an config file that is not added to source-control
If you have an older version than TFS2012 and thus can't create a .tfignore file or use the File > Source Control > Advanced > Exclude … option, you can try this:
Make a copy of the target file in Windows Explorer.
Undo Pending Changes (if any) on the target file in Team Explorer/Visual Studio.
Delete the target file in Windows Explorer.
Move the copy of the target file to the location of the deleted target file, and rename it so it has the same name as the deleted target file.
TFS now seems to ignore the changes in the target file. If you need to edit the file again, don't use Visual Studio, as TFS will then put the file back in the list of files with Pending Changes.
You can just simply select the file from your Source Control Explorer and Right Click on it, and the select the "Rename" option from there, and you can add ".exclude" at the end of the file name.
And then do remember to check-in the file, and after that you can see that your file is excluded from Source Control.
I have a multi-project solution being stored in TFS.
Each project has separate Debug/Release build configuration folder specified.
The main project's bin folder is "included" in source control because it contains some third party DLLs that are included in the repository.
Each reference is a "project" reference type as per MS/TFS best practices.
Every time I build the solution, VS/TFS copies all of the built dependencies for the main project into both the build configuration folder (debug/release), and the root bin folder. When the file appear in the root bin folder, they get added to source control (or if they were already there due to this same issue, checked out)
For now, I have removed the bin folder from source control, but this is less than ideal, because now each developer must maintain the local DLLs, rather than just getting them from source control.
My ideal solution would be to just use SVN instead of TFS, but I'm locked into this one.
What's the best practice in this scenario?
If you want to include binaries in your source control (and some people would burn you at the stake for doing so) I would do the following:
Create a "Binaries" folder inside the project
Copy the dependencies in there
Add references to those DLLS in that location
The project file will then contain relative paths to them, so you can safely include that directory in source control and have it work for all devs, without having to add your "bin" directory to source control.
After using the solution outlined in the above answer and comment, I've found that for some reason, one of the DLLs is not being copied to the bin folder when the solution is built. (Copy local is set to true for the reference.) The DLL is copied into the build configuration folder, but not the main bin folder. It is used in the application, so dependency checking should pick it up. As it is now, a runtime error occurs whenever code attempts to access this component (as would be expected with a missing DLL.
Any ideas?