I'm using the N2 CMS system for ASP.NET. Well I say 'using', I'm really just trying to develop a tiny understanding of it.
One of the things that's obstructing me is that it's set up in a way I've not seen before. Where are the codebehind files for the pages?
Can anyone tell me for example, where is the code for /Edit/default.aspx? How on earth do I debug what it is doing?
Thanks
David
It always used to be in N2.Edit.dll, but by the look of it they've rearranged this in more recent builds - I'm not 100% if it's now in N2.Management.dll or in N2.dll itself.
As usual the easist thing to do is to get hold of the source code (or an SVN checkout of the correct version), build it yourself and then replace the DLLs you were using with your built versions and their PDBs - you can then step into these correctly. You might want to go back to the regular releases for deployment, though.
If it's still Edit/default.aspx for you then I guess you're on the 1.5 code or thereabouts? In that case N2.Edit is built from src/wwwroot in the source code. You can just drop the entire src/wwwroot/Edit directory into place in your app and run it from the codebehind files there, not a compiled N2.Edit - that's easier to tweak, although I think it was easier to step through using a built DLL.
You may have to hunt around the build tree for all of the DLLs - I don't think they all get copied into one place. I used to take the DLLs from the N2.Edit.Tests project bin directory, and N2.Extensions and N2.Security from the N2.Extensions.Tests bin directory.
Related
So I'm left maintaining a proprietary codebase from a third-party vendor. The vendor is still sort of around, but support is limp. The site is ASP.NET.
I have made some changes but I am having a really hard time getting IIS to compile these changes in. The bin/ directory has what I believe is a precompiled dll for the core classes. I've changed these but it doesn't recompile. I have tried deleting the dll but then the app refuses to build saying that the Global.asax can't inherit the type anymore, so I don't really know how to rebuild with changes.
I spent all day Saturday setting up a build environment and trying to get a testing thing working. I have just been importing into VS2008 as a web site from the local IIS server. I got it to rebuild the app without changes, but it ignores changes I would place in it.
So I need to make a solution out of this website and/or directory structure so that I can do actual, big, full grown-up rebuilds and make changes to this codebase. Anyone know how I can go about this?
EDIT: A bit more elaboration. I've tried creating a blank project and just Add Existing File... on the whole website directory. This hasn't worked, it stops the import about 10% in.
Keep in mind there are two (actually, three) levels of 'builds' or compiles going on here.
1) The DLLs in the /bin directory should be pre-built, by visual studio or otherwise. The content of .ASPX, ASCX, ASHX, ASAX etc fiels are not included in those.
2) The ASPX, etc files I noted above are then compiled by IIS when the first request comes in (normally; there are ways to change that behavior). That is the source of the error with Global.asax you are seeing; With the DLL(s) gone, the class that Global.asax is supposed to inherit from does not exist.
3) Then there is the just-in-time compilation, which is not relevant for this discussion.
It sounds like you may be missing the source files for the project, or perhaps the web site is not getting properly set up as a project to compile that DLL
Try these links, I suppose this is what you are looking for.
http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/20/linking-files-in-visual-studio.aspx
http://support.microsoft.com/kb/306234
Not sure this question is really valid anymore. The source we were working with was rather different than it should have been. Not sure if someone got angry in the past and moved stuff around or what, but grabbing a new copy of the source fixed most of our issues. I am able to build now with an included csproj.
This doesn't really help many others with the same issue I suppose, but if you are getting weird build behavior like this, you might want to start with basics, like making sure that your source checkout is valid.
I am new in asp.net so I am not sure it is a professional way or not.
I have the project without .snl file. I just create a empty web site and then paste the files inside the folder where I created the project.
It worked for me.
I think pasting the files and folder directly by file manager will help you.
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.
So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
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 :)
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).