Related
Our company would like to upload an electron desktop application to Microsoft Store, so 3rd party contractors can use it for their work. It would be publicly available.
The applications is signed and it can be built to either msi or exe format.
Is it possible to distribute our app like this?
When a new version becomes released how much time would take for Microsoft to validate our app before it can be publicly available?
The application is under development. An auto update feature is planned to be implemented. Does Windows Store provide an API to check the available versions?
Please note that we don't have any C# developers or any licenced Visual Studio instances. We would like to use Javascript/TypeScript/Angular and shell script technologies. The executable is built on linux CI server using electron.js and mono with wine. The CI pipeline is already implemented, only publishing is missing.
Thanks.
MSI and EXE installers are not supported by the Windows Store. You need to package your app as an MSIX, as explained here:
How to build an MSIX package for an Electron application
The following article talks about the steps you need to go through for publishing an app in the store. Usually. an update should be validated by Microsoft in maximum 3 days, from our experience.
How to publish your MSIX package to the Microsoft Store?
Regarding updates, the store provides it's own auto-updates service, to ensure a consistent update experience for all the apps on the machine (instead of having each up launch it's own custom updater...). You don't need to write any special code for this.
If you want to enforce some update patterns, you can use the following API to check for an update in the MS store.
Disclaimer: I work on the team building Advanced Installer.
I have online web application with more than 10 web developer that work together on that web application, I don't want to install that application in there device, but I want to find away to make these developer work separately on the same application without make conflict in the code, I used bitbucket to solve that but they require to install the application locally, but for my situation I don't want to install it in there device for some reasons. please if any body have idea or tools that lead to solve our situation. thanks.....
Tools such as Bower, Grunt and Yeoman have surged in popularity recently.
Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.
Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).
How are these tools being used by ASP.NET devs on VS?
Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.
There is a Package Intellisense extension for Visual Studio which adds bower and npm package support
Grunt/Gulp launcher extension for launching grunt/gulp tasks
Read this awesome article written by Scott Hanselman for more info:
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
UPDATE:
These features are now fully integrated into Visual Studio 2015:
http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015
Great tips from john papa:
http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/
As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:
Some of you may ask, why not use NuGet for JavaScript? Why not extend
MSBuild for building CSS/JS? Simple. Because there's already a rich
ecosystem for this kind of thing. NuGet is great for server side
libraries (and some client-side) but there are so many more CSS and JS
libs on npm and bower. MSBuild is great for server-side builds but can
be overkill when building a client-side app.
So, use both. These are tools in your toolkit. Adding support for
Gulp, Grunt, Bower, npm (and other stuff, in the future if needed)
means a more familiar environment for front-end devs doing ASP.NET and
it opens the doors for ASP.NET devs to bring in the JS and CSS
libraries communities use every day.
Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."
Update
I'll stick some updates in here as I learn things.
So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.
New learning no.2: the tooling is not ready for prime-time enterprise dev.
The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.
Latest Node and some added command line options now make this better behaved.
Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.
Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.
New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.
Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.
With Bower updates are faster. Every time a new version or update is released we can easily find it in Bower. You no longer have to wait as we had to with NuGet.
So we could say that NuGet continues to be the king in the server side, but Bower is the new king of client-land.
Take a look in this post for more details and see a simple example:
http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/
To answer the original question with a perspective from both enterprise and casual development...
History
Visual Studio has always been a standard development tool for efficiently building large-scale enterprise applications for Desktop, Mobile and Web. This included both client-side and server-side web applications built using Forms, MVC and the .NET Framework. Of course, what makes Visual Studio so appealing is the power behind it, which gives developers the ability to quickly generate, or scaffold, common solutions via project templates - allowing developers to focus on solving business problems.
For simple client-side web sites that use a few libraries and require minimal data interaction, a tool such as WebMatrix would often suffice due to being lightweight and able to serve up web sites with ease.
Many of those tools and technologies can be found at Microsoft /web.
Divergence
At the same time, there has existed a burgeoning Open Source community that has been developing many of the libraries and frameworks that have risen in popularity for building modern web sites and web applications.
For developers working with the "Microsoft Stack" of technologies, the gap was originally bridged by integrating NuGet into Visual Studio. Many, but not all, libraries and frameworks were available as NuGet packages; and there was plenty of support from Microsoft for working with these technologies. Microsoft had also created it's own open source mini-ecosystem called CodePlex to support development and sharing of projects, usually focused on their technology in some way.
Unfortunately, while the availability of technologies was fairly up to date for Microsoft developers, it had become more and more challenging to keep up because it wasn't just about the libraries and frameworks, but the workflow and the way these technologies were being made available, integrated and used.
Such workflows include:
client-side package management via Bower from Twitter
(Bootstrap, etc.)
node-based package management via NPM
client-side application scaffolding via Yeoman (e.g. generators for ASP.NET and knockout)
automated task running via Gulp and Grunt
pre-compiling CSS from either SASS or LESS
transpiling languages such as ES6 or TypeScript
testing (Jasmine, Karma, etc.)
bundling and deployment (Webpack, etc.)
Unfortunately, much of this is a manual process, such as identifying the right package for the job or writing different tasks that can eventually be run automatically. Each is truly a subject in and of itself! It's not uncommon to end up simply looking up a package or command for something that in the end could - and Visual Studio developers would say should - be automated.
Convergence
Microsoft has been slowly moving from not only supporting open source development but embracing it. It has made many of its core technologies available to the open source community via GitHub, as well as it's own .NET Foundation movement.
A major effort to converge by Microsoft was to introduce Visual Studio Code for multiple platforms - offering a simplified development experience that caters to the workflow that has become popular with the open source community.
Still, Visual Studio Code can be viewed as a major step back for developers used to much of the power and simplicity offered through Visual Studio through its automation of tasks and project templates. Microsoft introduced Web Essentials for 2010 and 2013 editions to keep up; but as many have observed, this was simply more of an effort to show support rather than a full integration into developer workflow.
Behind the scenes, Microsoft was looking to put it's .NET Framework on other platforms and established .NET Core. As of Visual Studio 2015 - specifically Update 3 and Node Tools - there is much deeper support for the open source development workflow with integration of NPM and Bower, as well as task running. These still require manual intervention but it's on par with the workflow outside of Visual Studio. It still feels foreign, but it's getting there.
The Future
With all that Microsoft has invested, it is clear that the next step is to bring together much of the steps taken to embrace open source development by providing a more visual and automated experience to Visual Studio Developers. This will include templates that generate rich web applications which not only have all of the necessary packages and dependencies defined, but the ability to bundle for distribution.
In the meantime, I think this is a great time for Visual Studio developers to get a feel for the current workflow, if just to appreciate how "the other guys" have been doing it. It won't be long before much of it will be simply a click away.
I'm thoroughly confused about how to properly deploy ASP.NET MVC with my application. As far as I understand, there are the following ways you can get it on a machine:
You can download a separate installer and install it on a machine that has the approprite .NET framework (although which MVC version requires which .NET framework?)
Some versions come along with .NET framework itself (though I can't find which version of MVC is shipped with which version of .NET);
Some versions are installed with Visual Studio (though again, no idea which versions are installed with which versions of VS). In this case, you can set Copy Locally to true for these references and perform a "bin deploy". You might need to add some extra references though (not sure which though).
You can also download MVC as a NuGet package, in which case it also downloads some other unrelated packages like WebPages, Infrastructure and Razor (which is my personal WTF - wasn't Razor a core part of MVC?). In this case the build process will automatically do a "bin deploy" by default (I think...)
So... WTF? What is the proper way to add MVC to your development workstation, what is the proper way to add the references to your project (NuGet? GAC?), and what is the proper way to deploy it to the target server (separate installer? .NET installer? bin deploy?)
"Proper" Development:
The "proper way" (by which I mean standard/redistributable way) would be using Nuget for your references. This means you can easily manage different versions and anybody else working on your project has a standard repository from which to pull the external requirements.
The NuGet documentation has a decent explanation of how to add references.
To install the appropriate version of MVC for developing through Visual Studio, just download and install it from the ASP.NET MVC website. This will install the necessary templates for you to create a new MVC project in Visual Studio. This will also include the necessary binaries, etc.
"Proper" Deployment:
Use bin deploy to deploy to your webserver. This means you don't need full admin priviledges to install the MVC requirements.
Phil Haack's guide will walk you through the process of bin deploying MVC3+
Keep in mind, the web server does need the appropriate .NET platform installed. You should install this via the appropriate redistributable installer if it is not already installed on the server.
Referring to the deployment i publish my asp.net app (i usually make web applications) to the file system in a directory (you can set also a server there, but i don't like it) and make an upload to the server with an FTP client of all the deployed folders. All the changes that i make to the app after (like bug correction) i deploy all the app again and upload single parts.
I hope i get your question in part, this is my first answer in SO.
I am new to Umbraco and i have heard lot good about this cms.
I want to start Umbraco, but here are newbie questions.
How to Install Umbraco on my local machine.
Ones I make Umbraco work according to my need, what are requirement for deploying on Shared Hosting.
How to deploy on Shared Hosting Server.
Thank You.
Go for Webmatrix - Umbraco setup 30 sec.! www.asp.net/webmatrix
In answer to question 2. Yuo will need the dot net framework installed (4.0) - some hosts say it is but I have known at least one where the avertising blurb did not match the actual enviroment. You also need SQLExpress (2008 R2 is you best version). Once these are up and running, its the same as any database & iis app.
Another thing I found useful, is that Umbraco also provides a WebDeploy (http://www.iis.net/download/webdeploy) package that makes it very easy to deploy on IIS:http://umbraco.codeplex.com/releases/view/73692 look for 'Umbraco_4.7.1_WebDeploy_NET_4.0'.
I do the initial deployment on my development machine, the release to production could be as simple as a copy and paste (plus the db-release).
Hope this helps,
-covo
Umbraco ships in two type of packages.
Zip Package
Nuget Package
1) Zip Package
Zip package contains an Asp.Net website with Umbraco pre-installed in it. All you have to do is to extract the package inside a local directory, host the directory in IIS as a website and open in browser. Umbraco will guide you through the configuration steps, you can also install a starter kit that is a sample website template and is pretty fancy. Umbraco ships three starter kits along with installation package you can chose the one of your choice.
Step 1:
Navigate to umbraco download url and hit “Download Umbraco version*”: https://our.umbraco.org/download/
You’ll get a zip package of nearly 20MB size.
Step 2:
Extract the zip package into a folder and put that folder on any of your computer’s drive.
Step 3:
Open IIS Manager, add new website and point it to your Umbraco folder and start the website.
Step 4:
Now, browse this website, you’ll see the configuration page would appear, enter your name, email and password for Umbraco dashboard, remember your email id would be used as a user name for logging in dashboard. You can see you have two buttons; Install and Customize, Clicking install would get you the standard features in which you get “.sdf” database file inside your project’s “App_Data” folder. Customize on the other hand provides us with many handy configuration options. We’ll follow the customize route to get good understanding of the process.
Step 5:
When going for customized installation, you’ll see the database configuration options. Configure them according to your choice, Note that you’d have to specify a Database server and database name, you can create a new database on your server and you can use an existing database as well. Alternatively, you can select the SQL Server Compact Edition option from dropdown which would create “.sdf” database inside your project.
Step 6:
The next step in configuration would allow you to install a starter kit, starter kits are built in website templates. Let’s just select one of them for sake of learning although you won’t be needing them once you’d be well versed with the components in Umbraco Dashboard. Click on any of the three starter kits and let Umbraco do the magic.
It would take a couple of minutes and then you’ll be redirected to dashboard of your brand new website powered by Umbraco. Welcome to the Umbraco World. You can navigate to the installed website by removing Umbraco from URL. In our case http://localhost/ would show you the website
and http://localhost/umbraco would take you to the dashboard.
2) Nuget Package
Umbraco is also available in Nuget Package Repository. Follow the steps to install Umbraco using Nuget.
Step 1:
Create an Asp.Net or Asp.Net MVC Project in visual studio.
Step 2:
Open Package Manager Console and run the following command: “Install-Package UmbracoCms"
Umbraco will start installing inside your web application. Alternatively, you can right click on your project, hit Manage Nuget packages, find Umbraco CMS there and install it. There’s a slight possibility that your installation fails with error, normally updating the Nuget version solves the problem. Once the Umbraco is installed inside your project you can either run it by hitting F5/ Play from visual studio or you can host a website in IIS like we did in Umbraco installation from a ZIP package.
Step 3:
Once you've managed to browse your web application project in browser, All the next steps are same as ZIP package installation, specify login credentials, configure database and starter kits and Bingo! Umbraco’s installed.