We're developing a custom Content Management System in ASP.NET 4.0, using Team Foundation Server for source control. The database is hosted in a remote server, whereas the debug is done locally, thus new content (aspx pages) created by each member of the team is stored in our local computers and unavailable for other team members. I don't think adding those files to source control is the best approach, but the only other way I see is deploying to an external IIS for debugging.
Have you already worked with this scenario? Wwhat do you think is the best option? Thanks in advance
thus new content (aspx pages) created by each member of the team is stored in our local computers and unavailable for other team members ... I don't think adding those files to source control is the best approach
I really wonder why you think that is a bad idea... I think adding created code in your source control system is the very best thing to do.
What do you think happens if a computer stops working, gets stolen, etc? How do you obtain the file again? Store every file that is crucial to your system in a source control system.
I guess you can have a "tools" folder in project structure where you keep all of your test pages. Then when project is built that folder can be excluded from copying.
For example when Release build is executed "tools" folder is excluded, while Debug builds leave it in the project.
It really depends how do you guys work, how many of you there are, how often do you do delivery cycle - but generally garbage of test pages tends to grow all over the place (same as commented out code) if there is no systematic approach and whole project team chips in.
Related
How Can a Web Page Display What Version a File is In Program Files Directory?
For example, if I wanted to send a user a URL that would show the user what version of our software is installed (version number and release date) on their Windows PC. I'm just talking about file properties, not actually running something.
Is there a way to do this with .Net/ASP.Net?
The answer is no.
The best you can do with HTML5 or Javascript is to let the user select a file and even then you have very limited access to properties (at most name, size and type) without having the user upload the file.
The most efficient solution right now would be to serve a very basic clickonce application which would locate the files, read the properties and send the information back to the server. From there you can choose to redirect the user back to your website with the information you collected.
Generally access to the Programm folder is limited at best. There used to be a time when we even would write data like Configuration files there. That was Windows 95/98. And it was frowned upon back then.
With the introduction of NTFS with Windows NT (and later XP in the Consumer area), enforceable rules were put in place. Rights tend to be highly limited. This is even more true of Webservers, as they tend to be prime targets for hacking. The only rights you can expected a Webserver to have is read rights to it's programm and the content directory. Maybe if the admin is really nice and it really helps with performance, it might have write rights on a Temporary subfolder of Contents.
Reading out your version from a file is propably possible with only read rights, but not the right way. Usually you just let the compiler hardcode (insert as constant) whatever Version is given in the Project file or by the Version Tracking Software.
So the first thing is that you need some approach of Version Control. And then your answer depends "however this Version control mechanism does tracking of the Compiled version". There is some limited version tracking support in Visual Studio itself. But there is also full, 3rd party Version tracking Software.
We have an azure Webrole which we call as an API from other applications to convert webpages into a rendered byte array which we then attach as a pdf into emails. We do this using ABCpdf.
For our latest project we have to use a second engine from ABC (ABCGecko) in order to render our pages correctly. The ABCGecko engine requires manually copying to the output directory after build occurs, it doesn't happen automatically.
For a normal application this is no issue, I simply copy the required folder (XULRunner_38 for anyone who uses ABC) into the release after building but I can't figure out how to do this for an Azure WebRole and there doesn't seem to be anything much in the way of help from what I can see in google searches.
I'm assuming I either have to build the role and then adjust the package before I deploy, or deploy the role and then copy the folder across after. I can't figure out how to do this though.
If anyone has any ideas or has needed to manually copy files to an Azure Webrole in the past then I would greatly appreciate your help. Also I should mention that we use Visual Studio as our IDE and publish from within there in case that matters to anyone.
Azure web (and worker) roles allow you to define startup tasks, which allows you to call a script (e.g. powershell script, batch file) which can then perform actions such as copying files.
Oh, and if you don't want it to attempt copying in the event a role instance reboots, you'd need to do something like leaving yourself a "breadcrumb" somewhere to signal that you've already done your init work.
What you don't want to ever do is manual copying of content to your role instances. The moment those instances are updated (e.g. new Host OS update) or they're moved to another physical host, you'll lose any of the files you manually copied.
This is all independent of any IDE (aside from general support for the script language you're writing in), since your startup task is going to execute on each web role instance when it starts up.
More details about startup tasks are here.
Ive been away from .Net web dev for a few years and am now coming back to it inorder to update a client project. I've installed VS Pro 2015(legit no cracks) and am now experiencings some odd behaviours both with the project/website files and VS.
The first 'issue' I need to tackle is that when adding a new master page or webform to the project, these new documents appear completely empty. There is no code or markup generated in the documents eg: 'docname.master', 'docname.master.cs', 'pagename.aspx', 'pagename.aspx.cs'.
I doubt this is the correct, behaviour since it wasn't in the past. So have things changed, and this is expected, and I need to get up to speed. Or, is there something wrong with my set-up -which I expect- ? If so, do you have any ideas what I'm doing wrong? What can I do to rectify this?
UPDATE
I've just done some testing on a different machine and it appears that this seems to be connected to the fact that the files I've been working with are located on a network file server. Is this a known issue, and are there any fixes/workarounds?
In my case it turns out that the cause of this and several other issues was purely down to the fact that the project files I was working with were located on a network drive.
It appears that this is a fairly common problem, especially when access to the network / remote drive is quite slow.
Simply switching the project files to a local drive fixed all the problem I was experiencing.
Let's assume I'm going to create project in ASP.NET MVC 4 and users should be able to easily switch between test/demo database and production one. Both databases will have same schema, but different users and data.
Should I simply use two versions of web.config with different connection string and deploy it to two separate IIS instances?
I thought also about choosing database from dropdown list during logging in, so I would need only one IIS instance and one config with two connection strings. Do I gain anything from latter approach other than more complex code to handle it?
In our system we use web.config transforms and use MSDeploy with Publish Profiles in the project for our two different servers, Dev and Production.
To deploy to Dev, you simply click publish and select the "Dev Server" Publish profile and out it goes. Same thing on production, but you select "Production Server" from the publish profiles.
Dev and Production are two different physical servers, which is ideal. What if you do something where you need to reboot the dev server to test some big changes, or some new updates etc, you don't want production going down with it.
Our environment is virtualized so it was easy to create a production server and a dev server. Really we created a dev server and once done, we based production off a snapshot of the dev server, so they are basically identical with different code bases.
We also setup Visual Studio Remote Debugger on both servers so we can debug code without having to install visual studio on them.
Being on two different servers, they have different urls, e.g.
something.com
login.something.com
admin.something.com
dev.something.com
dev.login.something.com
dev.admin.something.com
Now, we also use twitter boot strap and out design has 2 columns on the left and 2 columns on the right for spacing. So when on the dev server, I render giant "DEV" images vertically in the column spaces.
I should also mention source control. We use SubVersion for a source control server and Tortoise SVN with the Visual SVN VisualStudio extension to keep our projects in source control.
It's setup to the point that any developer given access to the code can to a Get on the repository and open it in visual studio 2013 and click publish. The code is very easy to move from developer to developer.
We also have some versioned assets the site uses and we have the dev/prod servers setup with Tortoise SVN as well. E.g. EmployeePhotos are in source control, and a developer can add new photos to SVN and go on the server and go a get on the virtual directory containing them and they are uptodate. Handles deletes as well. If we delete a folder from source control and do an Update on it, SVN deletes the deleted images.
All code aside, I would host the two separately. The chance of someone screwing up production data when they think they're messing with test data is high enough that it's better to have explicitly different URLs. I'd even probably have visual cues in your Master layout (color differences, differences in the main page header,etc) to make it clear to the user where they are and what they're expected to do there.
Even if you're not worried about that per se, you're right that managing it internally will be more complex as well, and error-prone. I'd steer clear of it.
As described here, I'm writing a WinForms GUI that is run in an ASP.Net AppDomain.
However, whenever Web.config or the bin folder is modified, ASP.Net unloads the AppDomain, and the entire program dies.
Is there any way to prevent this?
2nd EDIT: In my EXE, I create the AppDomain by calling ApplicationHost.CreateApplicationHost and pass it a type in my EXE that launches the GUI.
EDIT: I'm already aware that this is a horrible design.
Does anyone have a sane alternatives?
The program tracks accounts for a non-profit organization in a typed dataset.
It needs to send bills by email, and I'm using ASPX files to generate the emails. (I'd rather not change that, unless there's a very nice alternative; the templates have already been written)
The email templates are ASPX files that are deployed in a subfolder; that subfolder becomes the ASP.Net application and has the executable in its bin directory for ASP.Net to load all of my code into its AppDomain.
The typed dataset must be accessed by both the UI and the ASPX files, and I don't want to download the data from SQL server twice
This is core to ASP.Net - if the web.config is changed, the AppDomain is recycled. If the machine.config is changed, all AppDomains are recycled.
However, you can disable this. Turn on "Disable Recycling on Configuration Changes" for the application pool you are interested in in the IIS control panel.
alt text http://img138.imageshack.us/img138/9938/iisdisablerecycle.png
See this question: How to prevent an ASP.NET application restarting when the web.config is modified?
I've noticed that your first question is dated Oct 29. I know it's far off on the development track...
But just out of curiosity: Why not use T4 templates?
It's simple, fast, you can edit pretty much like an ASPX page, and it runs in whatever AppDomain you are.