I just wanted to confirm, that if a build a silverlight application and the whole package including the dll consumed comes to 50 mb and then when user use this application in browser then does all the 50 mb app gets transfered over web? If yes then does there is any workaround for it?
Yes, the entire XAP file including the DLL(s) you have included will have to be downloaded. It is however possible to use the application library caching technique to make the download more efficient.
By checking the Reduce XAP size by using application library caching checkbox in the project Properties window, Silverlight tab, only the assemblies required at startup will be downloaded to begin with. Remaining assemblies (parts) are downloaded when required. The assemblies or parts will also be cached on the file system for later retrieval when the user revisits the Silverlight application.
Related
I'm looking for a way (using C# .Net or C++ and WinApi or anything) to add a layer between filesystem and client application to add custom behaviour.
Like OneDrive and Google drive application on Windows. You can browse files normally but if given file is missing from a drive it will be downloaded. I need to do something similar. And I need this solution to be transparent to other software (explorer and any other software that accesses files on drive).
I really even know what to call it. So if you have a name for that type of functionality please let me know.
Here are some approaches to building a virtual file system on Windows:
Using Cloud Files API. OneDrive is built using this API. It is designed for slow-speed remote (cloud) storage, such as Document Management System. Here are some features that it provides:
On-demand loading. You can load the file content into the local drive only when an application is accessing it the first time. The folder listing can be done during the first access to the folder.
Offline files support. You can pin/unpin files to keep on the local drive when the server is unavailable.
Download/upload progress reporting.
Integration with Windows File Manager. Each item shows offline status, pinned/unpinned status, in-sync status, and download progress.
Messages and error notifications to the user, as well as file system status reporting.
The driver that this API is using is installed with Windows by default and does not require installation. Here are some tools to build an OneDrive-like application:
CloudMirror sample in C++ from Microsoft. Code on GitHub.
User File System from IT Hit provides example in .NET. Code on GitHub.
Using Projected File System (ProjFS). It allows you to represent (project) some hierarchical technical data as a file system. It is designed for high-speed back-end storage, such as for example registry. Here is its major feature:
Hides the fact that the data is remote. The user "thinks" that the files are in the local file system and does not have any status information. The user does not know if the file content is available/unavailable or online/offline.
ProjFS is not installed by default and requires Windows component installation (thank you IInspectable for this info). Here are some tools to build with it:
Programming guide. Sample: Virtual File System for Git.
Using Shell Namespace Extensions. Typically used to create a UI extension for Windows File Manager. For example, Windows Recycle Bin and Printers are namespace extensions. They are not available via standard Windows File API and applications can not read/write to it unless it redirects to a real file system behind it. Here some features that it provides:
You can customize the Windows File Manager toolbar, shortcut menus, folder view, tree view, and status bar.
You can extend the Windows File Manager hierarchy, adding new custom nodes that look and behave like files and folders (cut/copy/paste, drag-and-drop, etc), without building a functional file system behind it.
Shell Namespace Extensions are part of Windows and does not require additional components installation. In many cases, you will use Shell Extension to add shortcut menus and items on a toolbar in Windows File Manager while building the actual file system using Cloud Files API or ProjFS. Links to start working with Shell Namespace Extensions:
Understanding Shell Namespace Extensions
Extending Shortcut Menus
What you are looking for is commonly called a "Virtual File System". To applications it looks like a file system, but the implementation is at your discretion, allowing you to materialize objects in any way you see fit.
On Windows you have several options to implement a virtual file system. The most common and widely supported infrastructure is the Shell Namespace. It allows you to register extensions, that appear as items (e.g. files or folders) in the file system. It's not entirely trivial to write a Shell Namespace Extensions, but it's not rocket science either.
A more recent addition to Windows is the Projected File System, that provides everything you need to build a virtual file system in user code. It ships as an optional component in Windows, and needs to be explicitly installed first. For an implementation that uses the ProjFS, see the VFS for Git github repository.
I want to ask you a couple of questions i looked in internet and didn't found an answer though...
I have an application for windows 10 PCx64 (artifacts of a built project C++/x64)
Is it possible to create odrinary Windows Store deployment file from folder?
How to do that? As i see MS is pushing new 'universal applciations' concept. But i don't want to rewrite apps entirely to .net/c#/Universal Apps. I just want to change build process so it will produce windows store deployment file, not MSI
Thanks!
You will soon be able to create a Windows Store package for a Win32 app and deploy it through the Windows Store. You'll even get access to UWP APIs and services :)
Subscribe to the "Windows Developer Preview Programs" to get some fresh news about "Project Centennial".
https://devpreviewsignup.windows.com/
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.
Are there any best practices on virus scanning all files being uploaded to the Sitecore media library (and ultimately stored in Sitecore's DB)?
I searched all over the web but there is too much noise caused by the word virus since many people seem to have performance issues on server that have anti-virus software installed.
I don't know if it is an established best practice, but I would probably add a processor for the uiUpload pipeline that used an API or command line process for a commercial antivirus product. Other than the fact that it is in a pipeline processor, it shouldn't really be much different from how you would do it in any other ASP.NET application. Performance will definitely be a concern, but you could create a dialog with a psuedo progress bar to give some feedback to the user.
Take a look at this post by Mike Reynolds. It may help you out:
http://sitecorejunkie.com/2013/11/09/perform-a-virus-scan-on-files-uploaded-into-sitecore/
I am not aware of any published best practices, but if you are able to add a step in the upload process, you might want to take a look at Metascan, which provides API level integration to multiple antivirus engines. Using this, you could build a workflow for those uploaded files to scan them prior to them hitting your Sitecore media library by establishing rules based on the results of the antivirus engines used in your Metascan deployment. There's also a hosted version at metascan-online(dot)com
Disclaimer /// I am an employee of OPSWAT, who produces Metascan, but it appears to be a potential solution to your issue
In one of our recent Projects, we were faced with a requirement to scan incoming files for virus. The problem in the project was that the files after begin uploaded, were made public available on the website.
The way we solved the problem was to implementing https://www.virustotal.com/. Its a free online virus scanner that has a public API. You can send files via SSL.
We implemented the solution by adding newly uploaded files to a Sitecore workflow. The workflow would handle the scanning of files, and move the files to the final stage of the workflow, if the files wasn't infected. If a file was infected, the file would be deleted.
A Scheduler is running every 5 minutes to check for new incoming files with the workflow.
This also means that the files aren't available straight away, as the scheduler has to check the file, but you should be able to implement the functionality directly when the user has uploaded the file, by adding your custom code to the upload pipeline.
I have created a windows service which checks for the status of the printer.
The user can download this service from a website. I need to query for the status of printers used by this user. So when the user clicks on the download button I want to store the user information in a file which my service can use. The service will use this information to fetch the printers from the database. I want to include this file in my installer. So I have to create the installer at runtime(i.e. when the user click the download button on my website).
How can I create the installer for the win service dynamically using C#?
NOTE: my win service is written in C++. I know about WIX.
quite a few years ago, when I did some work with InstallShield, it was possible to specify in the installer project which file(s) you don't want to be compressed and packed into the .cab files (or whatever they are called nowadays) when generating the installation package. Such a file would be left as-is and separate in the package, and you could later replace it with another file with the same name (I think I actually did something of the sort). So you can have a dummy file when building the install package, and then replace it on the fly with the right one.
I am not familiar with modern tools, but am quite sure this functionality is preserved as it is quite useful.
In WiX you can create custom actions which are arbitrary code you write (You provide the .dll which can be built using C++). In the custom action you can generate your user/location customization file.