I've got a app called packagetester with a /packages directory, and a local package called lauffenp:notifications inside of the /packages directory.
Here is the packages file from packagetester.
meteor-base # Packages every Meteor app needs to have
mobile-experience # Packages for a great mobile UX
mongo # The database Meteor supports right now
blaze-html-templates # Compile .html files into Meteor Blaze views
session # Client-side reactive dictionary for your app
jquery # Helpful client-side library
tracker # Meteor's client-side reactive programming library
standard-minifiers # JS/CSS minifiers run for production mode
es5-shim # ECMAScript 5 compatibility for older browsers.
ecmascript # Enable ECMAScript2015+ syntax in app code
autopublish # Publish all data to the clients (for prototyping)
insecure # Allow all DB writes from clients (for prototyping)
lauffenp:notifications
Now, if I run it in a single terminal using meteor, it works fine, it finds the package like it should and executes it.
However, if I open a second terminal and try to do the same thing, it can't find the package:
=> Started MongoDB.
=> Errors prevented startup:
While selecting package versions:
error: unknown package in top-level dependencies: lauffenp:notifications
Here is a screen capture of the app running on the left terminal and failing on the right terminal.
screen capture of app running/not running in two terminal instances
If I exit the left terminal, it won't run and gives me the same error. I have to meteor remove and meteor add to somehow 'reset' packages and then I can run it on one terminal.
How can I get meteor to 'persist' a local package?
The error you get on the second terminal seems to be related to missing packages, but in fact it is due to the fact that you are trying to run multiple instances of the same application within the same directory.
You cannot do that.
While one instance tries to build the app into the .meteor/local directory the other races to clean and rebuild and one of the instances lose track of dependencies, hence the misleading error message.
But if you check the previous warning on the other terminal, you'll see that the actual problem is multiple instances.
Namely,
if there is something else listening on 3000, you must run meteor on another port
if you want to run two instances of the same app, you must create another copy of your app folder, run the second instance from that copied folder and set it to listen on another port
Related
I have converted a Win32 Application to UWP using MakeAppX and it doesn't seem to run. When I click the icon in the start menu literally nothing happens except a busy icon briefly appears on the cursor.
I completed the same process with Notepad++ and all it's DLLs and that worked fine (using the exact same manifest file, just changing the exe)
My questions are:
Where does the UWP save files that it creates/temporary files etc? If I run an executable and it generates files next to it, where would that be when you run a UWP?
Can I set that location in the AppxManifest?
Is there anyway to see if it has run correctly or not?
Edit:
Could this be a file permissions issue? My application needs to write to 'C:\MyFolder' & creates a folder with a load of files next to the executable upon startup and that doesn't happen.
So looking into this a bit more I came across this blog which discusses preparing for conversion. I think the above file accesses probably contravene the following:
Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
This looks like a fairly halting issue, am I correct in that assumption?
If your app is writing to the install directory you will need to change that code to write to your local app data folder instead, as the preparation guide calls out.
Write operations to the install directory are not allowed in order to ensure the ability for the app deployment stack to perform seamless, differential updates and clean uninstalls of your app.
Btw, to debug through your app launch failures you can do the following in Visual Studio: Debug -> Other Debug Target -> Debug Installed App Package -> select your app from the list of installed apps.
I have two WPF applications in the same solution. One is a configuration helper for the other and needs to be run before the 'big' app is run. In the VS Setup project I have included the Primary Output from both applications.
I want to run the configuration helper during the Commit phase of setup so I added a Custom Action consisting of the Primary Output of configuration helper and marked the Installer Class as false.
When I run the resulting msi, both applications are installed in the same folder as desired, but I then get an error that 'a program run as part of the setup did not finish as expected.' The msi then uninstalls.
I was hoping the configuration helper would be kicked off as the msi exits, but would also be happy with the installer hanging open until the configuration helper exits.
What am I missing?
The program you ran as a custom action has failed, probably crashed. It may need some extra error checking or tracing to see what's going on. Programs that run as custom actions are not in the same environment as running them from the interactive user's desktop. The working directory is probably not what you expect (so file paths must be specified in full) and it's probably running with the system account, because that's the way Everyone installs work, so any assumptions about user locations (including the interactive user's desktop, user folders, access to the network, access to databases, ability to show forms) will be wrong and are likely to be failure points. It's better to run configuration tools like this when the app first starts because you are now running in a normal user environment.
I'm currently working on a fork of the Meteor application Rocket Chat. I have a requirement to stand up the application for testing and development on an isolated network, so no internet access whatsoever.
I can't just get it running on a connected system and then copy it wholesale into the disconnected lab. Rather, I need to be able to check out a copy of the source code (from a local SCM) and then run Meteor, letting it perform all necessary compilation and dependency resolution on the fly.
Even though it is a huge kludge, I was hoping that I could just copy the .meteor folder from a working system directly onto the target system so that it would already have a cache of all required packages and therefore not need to reach out to any repositories. However, from what I have found, that only works for Meteor dependencies downloaded from Atmosphere.
Within Rocket Chat, there are several private packages (such as rocketchat-ldap) that have dependencies on NPM packages (in this case, ldapjs). When the application is run and these packages are built, the .npm folder in the user's home directory gets populated with those NPM packages. So, I tried to package that folder up along with the .meteor folder to accomplish the same task.
Unfortunately, when I tested it on the offline system, despite having the populated .npm folder, Meteor spits out the following error:
While building package rocketchat:ldap:
error: Can't install npm dependencies. Are you connected to the internet?
Obviously, I'm not connected - by design.
So, I am currently looking into Sinopia to stand up an NPM repository mirror on our local network that can host these dependencies. However, I have no idea how I'm supposed to point Meteor to the alternate server. The Meteor documentation includes information about the Npm.depends and Npm.requires directives, which the application uses, but I can't find anything about specifying a URL from which to find said packages.
Further, is it possible to do something similar with the Atmosphere packages? Or is copying the .meteor folder the only way? As in, is there some application out there that I can use to host some of the Meteor packages? Or am I going about this in the wrong way?
The solution I went with, which isn't as elegant as I'd hoped was the following:
First, I copied the .meteor folder from the user account of a "working" system (this contains the Meteor executable and all of the Meteor packages downloaded from Atmosphere) to the user account of the disconnected target system. This allowed the target system to run Meteor.
Second, the NPM packages in question were being downloaded directly into the private packages in the source, but the .gitignore file on the source was set to ignore the node_modules folders. So I altered that and then checked those node_modules folders into the source with the rest of the application.
So, for example, the application source included a /packages/rocketchat-ldap/.npm/package folder. Then, when the application was run using meteor, the associated NPM packages (such as ldapjs) would get downloaded directly into a node_modules folder in that folder structure, at which point the private packages could be built.
Now, the source code in Git already contains those downloaded packages, so when a copy is checked out onto the disconnected target system, there is no need to download them.
Fortunately, this did not increase the size of the source very much (just a few hundred kilobytes).
The result is that when running meteor to run the application on the target system, all dependencies are already in place, and no internet connection is required.
For production why should I "bundle" the meteor application and not just copy
the sources on the server use the "meteor" command?
Basically what is the difference between:
"meteor bundle app.tar.gz", then installing the right version of fibers and nodejs
and extracting the archive and starting with "node main.js" the app,
and copying the project sources on the server and just writing "meteor" to start
the app?
This won't be an exhaustive list, but here are some things that the meteor command does:
creates a local database
watches on every dependent file in your app or in your packages
sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)
In contrast, bundling an app:
does not create a local database
does not spend CPU watching your files for changes
creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.
In general, deploying shouldn't be a huge pain if you use a good set of scripts.
When using a bundle:
It will not spawn meteor-mongo(Mongodb inside meteor)
No hot reloads
Meteor will not watch your files.
You can leave/quit the server without killing your app.
You can manage node processes smoothly by using pm2 or other similar npm packages.
You can decide where to put your mongoDB and decide what port to use.
You can connect to your mongodb remotely by not having to run your meteor app.
While using a copy or running meteor command in the project directory:
You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
You are letting meteor to watch over file changes which uses CPU.
When your app dies, your db dies. :)
I've an application that is published on meteor hosting using command :
meteor deploy spyermeteor
The application is rendered on http://spyermeteor.meteor.com but no data is used on client side.
I can see that application is running well on server-side if i do a :
meteor logs spyermeteor
I then check the browser console and i see that i can access database :
Annonces.find().count() // per exemple
How do you explain that reactivity doesn't work on client-side ? maybe something is wrong with my conception but on my computer (windows) and on a VM (Linux debian) it works well.
Any help is welcome.
The source code is available here http://www.github.com/Rebolon/spyerMeteor
In production mode all files are concatenated and minified into one javascript file. If there is even a slight syntax error somewhere in your code the rest of the code will not execute.
Looking at your deployed site you have to split your client and server side code. I receive an error
Uncaught ReferenceError: Npm is not defined
This is meant to only run on the server but the code where you use Npm is being run on the client when it should only run on the server. It would also cause an error in production mode but since the files are not concatenated & minified the error wouldn't stop other javascript files from running.
You can either move this code to a file in /server or into a if(Meteor.isServer) {..} block
It also looks like your code is made for <= Meteor 0.5.9. You should upgrade your local instance to 0.6.2 and look for all these exceptions in your js console before you deploy your app.