Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
Related
I have always used the express versions of Visual Studio for my Asp.Net projects. In the past, I would use a basic FTP synchronizer to push updated files (*.vb) to our server, then the changes would just show up on the website instantly. Now, for some reason, when I make changes to our *.vb files, they are not being reflected on the server after I synchronize over ftp, unless I build the project first. In addition, for our .Net 4.0 project, VS 2015 14.0.23107 is adding the following directories, with tons of stuff inside of them:
/.vs
/My Project
/Obj
There are loads of files within these directories which I have no idea what they do, and for some reason our project has taken on a completely different behavior. Now when we try to synchronize over FTP, there are a ton more files, and it seems that changing the actual underlying source doesn't work. We have to synchronize all the other files in the above directories, then we can see the changes.
Is this a new way they are doing things, or is this because VS is now free and we are getting a better version where we have to "publish" not "synchronize?"
Is there a way to go back to the simple way of doing things, where we just have a plain directory with our source files and sync them over to the server? Should we not do it this way? If not, what method should we be using and what files should we be pushing to the server?
I'll just promote my comment to an answer. There are several aspects of this question:
Use publish, this feature is already for long available in Visual Studio and works well. There is plenty of ways to customize it and it supports a lot of technologies, including FTP. It's also more convenient, systematic and reliable way of deployment than manually copying files to your FTP. You can also share your publishing configuration among developers and store several of them. No loss here.
I don't quite get why would you like to copy the source (.vb) files to the server. What you would usually like to achieve is to get compiled DLL's + resources copied to your server, and source files 'secure' on developers machines. You can compile your sources on the server if you really need it, but then just plug it into a source control, use ms build etc. Anyway, build/publish actions are there to prepare the deployment files for you, manual copying is pure bad.
For the new folders:
Obj is everything but new, its created to store some resources, crap, more here: What is obj folder generated for?
.vs stores user specific settings, and you should ignore it as well as obj folder, more here:
Should I add the Visual Studio 2015 .vs folder to source control?
My Project is most likely your own folder, nothing related to VS.
To sum up, as long as you use asp 4, 4.5 nothing changes. Only the 5.0 intruduces a bit different rules for deployment. Most of the problems you get are easily solved using the right tools (Publish). It will know what files to ship (binaries + resources included in project) and what to ignore (source files, caches, crap). It's convenient, less error-prone and can do much more for you.
Definitely, use "Publish" option (right click on your web application at solution explorer, under Run/Build options), thus you can update your server site with those files created on Publish. As Mikus mentioned, you DON'T need vb files on your published site, you just need dll's and resources (images, js, css, resx, e.g.).
Regards, hope it helps.
Use the Publish Option which is provided by Visual Studio.
This will compile your project and you can then host this in your reliant manner.
I personally host on IIS and considering I have no data stored locally I can publish directly to the published path on the IIS Server.
The Publish tool is very simple and only takes a few minutes.
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.
I have an ASP.NET application in VS2008 that is growing larger and am developing and testing on IIS7, not Cassini/IIS dev, so when I make changes, I publish, run and test.
The publish is taking longer and longer, since there are more and more builds for different projects within the solution. If I want to make simple changes to say an aspx file, instead of publishing, I just modify the published version to avoid the cost of the publish which is a pain.
Is there a better/faster way? Is there something out there that talks about best practices/efficient publish/run/test techniques for VS2008?
Personally, I just created a virtual site in my IIS running on port 1337 (Ye, I'm a geek, but I find that funny :P ), which points to the root of my project. I keep a browser open on localhost:1337, press F6 in VS and then F5 in my browser - no need to publish :)
Works like a charm :)
simply try to separate data, auto generated files and business layers in different projects, so you won't need to build the all solution, just parts of that.
Also make a clone locally, make changes and publish online using repository tools, like GIT or SVN.
Is there a tool or some general approach to packaging all the files of an ASP.NET application into binary form to prevent modification once its deployed? I am thinking there would be a set of signed binaries and a config file for settings that we allow the customer to modify. Has anyone attempted this, is it even possible?
I would pay a reasonable amount for a slick commercial product that did this with minimal hassle.
UPDATE
Sorry, from the answers I can see that I wasn't clear. I meant literally packaging ALL files, not just the code files. This means aspx, scripts, images etc. I'm not trying to prevent reverse engineering... this is a supportability issue, i.e. to avoid dealing with problems brought about by customer messing with the files.
If you made a web application project than you can compile your code into a single dll file. You can find it in the bin folder.
Just use aspnet_compiler.exe to precomple everything and then use aspnet_merge.exe to roll up all of the compiled assemblies into a single assembly. You can use an obfuscation tool like DotFuscator if you want to make it more difficult to reverse-engineer. Visual Studio pro and up include a "lite" edition of Dotfuscator that you can use for this.
Your codebehind files will be compiled in a single dll as ZippyV already mentioned. The aspx files will get deployed normally on the webserver.
But still, your dll files can be disassembled quite easily. So to be sure you have to use an obfuscator.
If you mean ALL files including the aspx you could also consider ngen. It precompiles everything into a dll so you can't even get at the aspx pages.
Although, ngen was designed to get rid of the JIT compiling feature of the framework and is definitely not a generally recommended approach but it may work in your case well.
From VS2008 select the menu option "Tools" and then "Dotfuscator Community Edition". You will have a "Learn More" link after it starts up.
I also sign mine using SN.exe to make it have a strong name. Given all this, I think it is complicated enough to figure out a system if you are given the source code and help.... so I don't worry about it anymore.
maybe Dotfuscator your customer won't be able to modify it nor reverse-engineer it :)
Right now I'm working with an ASP.NET website that automatically generates images and stores them in a temporary folder. When working on my local system these go going into a temporary folder that gets picked up by Visual Source Safe which then wants to check them in. As such, I am wondering if there is a way to just exclude that particular folder from source control?
I've done a bit of reading and found that there are ways to do this for individual files, but I haven't found anything yet about an entire folder.
I think you've found one of the main reasons MS went back to projects in VS2008 and in MVC.
It's been a long time since I've used VSS (mainly because it's really out of date now), but most source providers let you exclude files and folders as a setting of the provider, rather than the project under control.
If you can switch to a Web Project rather than a WebSite then do so, otherwise I'd look at updating your source control provider, as this sort of exclusion is easy with Vault, CSV, SVN, Git, VSTS and so on (to name but a few).
Are you using ASP.NET Website or ASP.NET Web Project? The difference is significant enough to solve or promote this problem.
Websites, love to scan the file system and auto checkin.
Projects, checkin only what you tell them to.
Also Visual Source Safe is pretty out dated, most recent source control systems allow you to do what you are asking. SVN and TFS 2008 SP1 do from my experience.
You can also try to right click and pick "Exclude" on the folder, but in the case of a Website I believe this renames the folder.
I'm not sure if this is an option for you, but if you exclude your temporary folder from VSS (delete the folder inside VSS using the VSS UI), the files that go into it should not get "picked up" again.
If you perform operations on a parent project of the temporary folder, you may try cloaking the folder.
http://msdn.microsoft.com/en-us/library/x2398bf5(VS.80).aspx
I would suggest emptying/deleting your folder from your website. Have your website on startup create/verify the folder, and on shutdown to clean it up and remove anything in it. This can be DEBUG code only (wrap in #if DEBUG) if so needed. Also add a build script to your project that does this every time it is built also.
Could you just make your application write to a temporary folder that is outside of your website?
e.g. in C:\tempfiles
VSS shouldn't be able to pick it up then.