I am trying to finish up my applications but encounter a big problem.. I have 3 applications that will display on different page. ex:product.html will contain product.mxml, new product.html will contain newProduct.mxml,user.html will contain user.mxml....
They are three different projects and I want to put them together in a website. My problem is that I can't put all release build files in the same main folder because the release applications all share the same name..ex:rpc_4.0.0.13363.swf,swfobject.js,gateway.php,framework_4.0.0.13363.swf and bunch of folders. Only the application swf is different. ex:product.swf, newProduct.swf...
I can't put them together under the same main folder. Also, my product application can upload image file into the asset folder UNDER the product application but I also need user application be able to see the image file that was uploaded to the product application.
Again the problem is, I can't put all 3 application together under the same main folder....what can I do?? Please help me! I really need this done. Thanks!!!!!!!!
The files which are the same are used by all your applications (they are the standard flex libraries) so you should be ok with copying all the swfs which are specific to your code (just the product.swf, newProduct.swf, ...) to one of the folders, and it should all work.
Related
My searching skills seem to be failing me on this one. It is a simple question;
In ASP.NET is it possible to store class files in a folder not under app_code?
What I am trying to accomplish is create class files which when added (or modified) to the web site will not cause the web site to restart. Anything under App_code or in the bin folder causes a restart. We are not using .NET for the presentation layer.
My reason is simple, we make changes somewhat regularly, and I do not want to wait until a specific time to add/change a feature. These are 24 hour websites and there is no great time to restart them.
Edit:
I am using FluorineFX to access the middle tier. I created a folder called "ProdCode" from the root of the application. When I try to access the NameSpace ProdeCode, class Employee_Calendar method getEvents. I get the error "Failed to locate the requested type ProdCode.Employee_Calendar"
Well, the goal of a non-restart is huge different, and HUGE separate from that of being able to place code modules, or class modules in some other folder.
When you build the project, most of the modules (and class ones) are crunched down to a single .dll anyway.
So, while you are free to add new folders and inside of those folders add new code/class modules? That may not well eliminate the need for the site to re-load, or in fact the site to re-compile the code again.
All of the app_code, and any other code module will crank out and result in a single .dll file. So, I don't see how you going to gain, or win anything new here.
What you could perhaps do is build some classes outside of the project, compile them, and then set a reference to the external code (and class) modules in the other project. That would suggest a external .dll. This would work during debugging, but an "il-merge" usealy occurs when publishing as non debug, and thus the gazillion .dll's are merged into one.
So, separate out code - great idea.
Adding code to additional folders - sure - no problem (do right click on the given class, or code module and make SURE the build action is compile - this is a default for app code - for other folders I can't remember. You need to check this.
so, up to this point? Hey, all great.
But, to save site re-compile time? No, this where train is flying off a big broken bridge, and the whole she-bang is crashing up in a HUGE ball of flames.
You might be able to same some time during debugging, but those included module are pulled into the "main" .dll (same name as your applcation). Go check the "bin" folder now - you not see the app_code .dll's but only one main .dll with the name of your project.
Such re-compile time is useally rather fast for the site to re-load. I you are just changing markup, then fine. But the idea that you want to include compiled code, and attempting to avoid a re-load? No I would not consider this - even if you could! I mean, how many times have you seen code fail or NOT take even after a publish and FORGETTING to re-start the web server? Those .dll's are often loaded into memory, locked and 100+ more issues exist. I many a time lost half a day because my .dll's did not take (due to me not re-starting the web server). there is pain and then there is this kind of "pain" in which parts of your application don't load. I just can't imagine the risk vs rewards in trying to save some time??? - I must be missing something here?
I have a big ASP.NET application (legacy) which actually (functionally) is composed from two portals. So I need to split it to two separate applications, to ease the development on each of them.
Of course there are shared features between the two. Some of them are in DAL and BL, and that is not an issue - all that code was separate din separate projects, which made up assemblies that are to be referenced in both apps.
But the problem is with some pages, lot of user controls, some css and javascript files, which are shared between the two "portals" (applications).
I'd like to ask for some advice on how to handle them. My main concern is to avoid duplication, so ideally they should stay in a single place, and be used by both apps.
First I tried was to add files from one project to the other as linked files. While this works for code file (they get built into the project they are linked to), it doesn't for aspx / ascx or css / javascript / images. It does if I publish first (if marked as content, they get copied during publish), but I can't do this all the time during development, and such files are not found when app is debugged / run from source code (sincve, obvious the linked files are not actually available in app file tree, when one is looking for any of them.
Another thought was to create pre-build event, and in that to copy all shared files from a common location.
e.g. I create a project Common and put there all files that are shared between applications, organized on folders, and on pre-build I perform an xcopy.
And another thoughts is to make all shared files part of a SVN repository which I reference with svn:external, in both projects.
But all looks to my little cumbersome. Does anyone had similar situation? How did you handled it?
Any advice on any of my suggestions?
You have, at least, two options :
sharing through virtual directories : https://stackoverflow.com/a/13724316/1236044
create user control libraries : https://stackoverflow.com/a/640526/1236044
The virtual directories approach seems straightforward for ressources like css, js, images.
I also tend to like it for sharing user controls.
The library approach should need more work, but would ensure better reusability of the controls on the long run.
I had an identical problem this week with css and javascript files triplicated across three legacy projects.
I removed the files from two of the projects and replaced them with linked files to the first project, but when I ran the website I got 404 errors for css & javascript files missing in the pages belonging to the two projects.
So I simply added the nuget package 'MSBuild.WebApplication.CopyContentLinkedFiles' to my solution and everything worked fine - the css and javascript files were deployed fine for the two projects and my 404 errors disappeared.
I didn't have any shared .aspx / .ascx files, but I would imagine it will work for them too.
See also this question / answer.
I have a website with huge number of pages, i keep pre-compiled version (with fixed naming) on production server.
Every time i make any change on my code i have to Publish the whole website just for a small change.
It takes about an hour to get the website published before i can deploy my changes to production server.
Is there a way to publish only a batch of pages so that the Publish process is faster?
Is there any other option to save the publishing time?
NOTE: By publishing I mean pre-compiling
Any suggestions are welcome.
If you're modifying only the html tags (nto the server side tags) or css, you can deploy only the part you changed.
If it's compiled code you got no choice.
I think you might have to ask your self why it's taking an hour to publish your web site ? Is your compilation time that much long ? .
One method to reduce the compile time, and size of a web-site project is to split your website into several smaller and more maintainable sites.
You can still deploy these separate publishes together in production.
References to pages from other projects work perfectly. All your pages within the same application on IIS will share the same session. So to an end user, this will still appear to be one website.
Since you reduce the work to be done while publishing any given module publishes will be faster. Divide your modules as per what you see as a suitable batch.
You must be aware of this, but I will say it just for completion. When you publish a website you get the option,Use fixed naming and single page assemblies. Select this to have a different dll for each page in your bin directory. You only need to upload the pages and corresponding dlls where you made changes. If upload time is a concern, this will take care of it.
Microsoft doesn't really have an idea of "pre-compiling" if you notice your pages have 3 components to them, the *.designer, *.aspx *.cs. The *.cs all needs to be compiled into a *.dll to be deployed to your website. Traditionally there are two types of executables, exe's and dll's. Asp.Net websites are compiled into a dll for all the code behinds that run on the server. Microsoft does not have a way to "half" compile a dll and then merge it with the other half you haven't changed.
If your website is taking that long, to compile & deploy. I would suggest you have more of an architecture problem then a code problem. Where I work our main website is 3,000,000+ lines of code, to accomplish everything the user needs to do and does. We don't take an hour to deploy. however what we have done is broken our business logic up into a number of dll's over 100 dll's and our website project in and of it self is just the aspx and the bare bones code behind to drive the flow through to our business logic. This allows us to alter x number dll's with our changes to support a new feature, We don't have to deploy all 100 dll's every time just the ones that have changed, that's the nature of dll's. if our business logic was 100% contained in our website project, then our compile, deployment would be significantly longer.
You want to consider refactoring your code into dll's. Another option if you're not married to the ASPX/ASP.NET solution is to consider an ASP/MVC.NET solution. I would consider refactoring your site. If it takes that long there's some serious issues, even if you could break Data access into a separate dll, then you wouldn't have to constantly compile & deploy the dll which handles your data access, every time you changed the website, only when you changed the Data access layer as well.
As previous posts mention, you cannot do this in an automatic fashion, but you could manually deploy your files if you want to reduce your publishing time.
When publishing a website, all code files for your site are compiled into a single .dll file in the website bin folder and all .aspx files are be deployed to their relevant paths.
To update the site manually, simply build the website on your local machine to create an updated .dll and overwrite the .dll in the bin folder on the production server. If the source/HTML has been modified on any of your actual pages/.aspx files then you will also need to copy them over.
Steps:
Build website locally
Overwrite production server .dll with locally built .dll
Copy any .aspx pages to production server where HTML/Source modified
Very simple.
Have all the HTML content stored in separate files to the code. A database would be an excellent idea. All one would have to do to change some text or swap an image would be to go into the database or file for that content and change a few tags. I recommend MySQL.
:)
I have an ASP .NET Web Site Project that is being moved into TFS. There is a folder that is used for user uploaded files (e.g., company logos, excel spread sheets, etc.) that need to be kept. I'm trying to figure out a good way to manage these files without placing the folder in TFS (it's really big), and make it easy for new developers to grab the folder structure to their local machines for development.
I was thinking of doing the following and was wondering if this is a good way of doing it, or if there are better alternatives:
Create a script which will, when executed, create the folder structure of the storage folder. This would be placed in source control.
New developers could grab this file and execute it on their local machine.
To make sure the folder is added to source control, get the developer to remove it from their local project.
Store the folder on a NAS - no need for the files to be part of the source-controlled code.
For example how this site is organized?
What i do not understand is what they upload to the Microsoft server?
I have created, with Visual studio, a very small web-page and i have to upload the whole site, even after the smallest change...
The usual approach is to replace everything with xcopy or the publish function in visual-studio, and in some cases replacing everything is the only approach - for example if you're using the web-application project model everything gets packaged into a single assembly and there you go - even to apply a small change you'll have to re-deploy the whole thing.
An alternative to this could be the Website model in visual studio, using which you should be able to deploy single code files on your server and they should be picked-up if you re-start the website from the IIS management tool. This model - in fact - works in a different way compared to the web-application project model. It's just a bunch of code files that will be dynamically compiled by the ASP.NET runtime.
Even if possible though - I wouldn't suggest the approach of deploying single files - as this is easily error prone (you deploy the code-behind and could easily forget to deploy the aspx counterpart, or similar). Unless you're delpoying Gigs of stuff over slow-networks, redeploying the whole thing is always the safest bet.
Have a look at this and this interesting links to find out more about website and web-application project models in visual studio.
It really depends a lot on how you're building your app.
If you're in VS and you're doing an ASP.Net site, then you can either do it as a Website Project, or as a Web Application project.
in the former case, your files will remain as aspx and .aspx.cs files and you xcopy (or FTP) whichever files change. if you want logic that's outside the scope of a single page, you'll either create a separate class library project or else use the App_code directory.
In the latter case, you'll compile all the logic into one or more .dll files that get copied to your site's /bin directory, and any number of aspx files that can either stay as such or be embedded (recommend leaving them as aspx files). Again, if an aspx file changes, you just movethe one that changed, if anything in the dll changes, you replace a whole dll.
All that said, a huge chunk of what's on the site you posted is probably being pulled out of the database. Most sites now dont' have content on pages, they just have organizational (view) logic on paes, and have other classes which fetch the actual content out of a database to serve up. This allows greater reuse and means that the 4,000 pages (number chosen at random) on MSDN don't have to be each coded individually as an HTML page.
After Googling i think, the check-box Use fixed naming and single page assemblies in the publish Website form of the Visual studio, is the right choice.
Although it might slow things down...