Can i place native dependencies in a subfolder - .net-core

When i publish a dotnet core project, it generated a single folder with hundreds of framework and native runtime files in it.
I understand that these files are required to make everything work, but can i move them into a subfolder and still get my app to run?
For example
MYAppFolder\
MyApp.exe
MyApp.exe.config
native\
hostfxr.dll
netstandard.dll
...
Is there some sort of probing path configuration that can do this?

As far as I can see you have a Standalone (SCD) app.
For that type of deployment hostfxr.dll should always exist in the app directory by convention.
As to other deps, you are able to move them to any locations, however you'll need to edit [AppName].deps.json for every build and also specify Additional probing paths. Besides, you are free to remove all the redundant dependencies (from deps.json and the file itself) if you are sure that you don't use them.
Check this demo where I've put all the dependencies of a Standalone app that could be moved to other location to a lib subdirectory.
please, note the following:
Additional probing path is set in HelloWorld.runtimeconfig.json but you can also use --additionalprobingpath [path] argument or Environment varibable
I've removed relative paths in deps.json file because otherwise I would have put the files to those relative paths sub directories - Additional probing path is considered to be a NuGet package cache thus have a package layout inside.
Also, consider having a Portable (FDD) type. You'll have a much less footprint and more flexibility arranging the files.

Related

Flow: resolving modules in a monorepo that uses Yarn workspaces

We have a monorepo that uses Yarn’s ‘workspaces’ feature, meaning that whenever possible, Yarn will hoist dependencies to the monorepo's root node_modules directory rather than keep them in the individual package's node_modules dir. This relies on Node’s module resolving algorithm, which continues to search for modules in node_modules directories up the dir tree until it finds the required module.
When using Flow types in a file that imports another package (internal or external to the monorepo), running Flow inside the package that contains that file causes a Cannot resolve <package-name> error to be thrown. It seems like Flow uses a different module resolving algorithm, and fails since the installed modules are hoisted to the root dir and Flow does not continue to search up the dir tree.
Is there a way around this other than running Flow from the root? Running from the root is less than optimal because it does not allow different settings for different packages in the monorepo.
Node version: 10.8.0
flow-bin version: 0.78.0
I also ran into this problem
To fix it need update .flowconfig:
[include]
../../node_modules/
FS struct:
/project_root
--/node_modules
--/packages
----/module1
------.flowconfig
Pick the components to be hoisted by hand with a directive like:
"nohoist": ["**/npm-package", "**/npm-package/**"]
or select them with an exclude glob:
"nohoist": [
"**/!(my-site|my-cms|someones-components)"
]
See my answer to another question for more information.

The output directory is under your source tree in meteor

how do I solve this
The output directory is under your source tree
warning:the output directory is under your source tree
your generated files may get interpreted as source code
consider building into a different directory instead meteor build ../output
I apologize for my ignorance on this matter, I am new in the world of programming and meteor. about my case. 1. I have a folder on Desk called “Findme” where I have the structure of my project (the code and everything which forms the application which works) 2. Then through the console I access that directory findme and then run the command meteor build/Desktop/MyApp --server = https: //findme.com, and start downloading. 3. But inside the console I also get the message indicated before and when it is finished, and I check the folder MyApp, it is empty. 4. And when I check the Findme folder it has created a folder named ~ and inside displays a file called Desktop/MyApp but it also doesn’t have any useful files, only winrar and nothing useful. 5. I am trying to generate the apk, could you please let me know what I might be doing wrong? Is there another way to generate the apk? I would appreciate it if you could help me!
Your should specify a path for where to build your application that is outside of your project directory.
Otherwise this can lead to problems with Meteor's file watcher and as your error already pointed out:
your generated files may get interpreted as source code consider
building into a different directory instead
So if your command uses a relative path, as used in meteor build ../output then it is important to call this command at the most upper project folder.
Consider the following project structure:
/myapp
/client
/import
/server
If you call meteor build ../output from within /myapp it will generate the output folder as expected outside of the project:
/output
/myapp
/client
/import
/server
However if you call it from within a subfolder, say /myapp/imports it may generate the output within the project like so:
/myapp
/client
/import
/output
/server
So keep this in mind when building your app.
Further readings:
https://guide.meteor.com/deployment.html#custom-deployment
https://docs.meteor.com/commandline.html#meteorbuild

Change the location of the node_modules folder

I'm currently trying to migrate an old ASP.NET WebSite project to Visual Studio 2015. I'd like to use NPM/Gulp to automatically compile LESS files to CSS (this task was done by WebEssentials in VS 2013).
I added a package.json file to the project to load the required components. This creates a node_modules folder in the root of the WebSite project, and this is where my problem starts:
Since WebSite projects don't have a project file, all files (and sub-directories) found in the project root folder, are automatically part of the project. Due to the deeply nested directory structure inside node_modules, this leads to errors because of too long path names.
An easy workaround is to set the hidden attribute on the node_modules folder (but this has to be done manually by each developer).
Is there a way to tell NPM to put the node modules into another directory e.g. one level above the project (..\node_modules) where the solution file is?
Or is it possible to set the hidden attribute on a folder from a gulp-task (which runs when the project is loaded)?
Based on #Rik's answer, I was able to solve the problem:
Instead of adding the package.json and gulpfile.js into the WebSite project, I added them at the solution level (as solution items). This means, that the node_modules folder is now in the solution directory at the same level as the WebSite project(s).
The only other change was to modify the paths in gulpfile.js accordingly.
You might want to check out npm 3.0+. It installs the modules in a maximally flat structure. It should reduce the paths lengths in the module directory.
From the release notes
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
#3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other
standard tools to deal with.
#6912 (#4761 #4037) This also means that your installs will be deduped from the start.
#5827 This deduping even extends to git deps.
#6936 (#5698) Various commands are dedupe aware now.
This has some implications for the behavior of other commands:
npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it
would only remove those that happened to be installed under it,
resulting in left over cruft if you'd ever deduped.
npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
#6937 npm dedupe now flattens the tree in addition to deduping.
https://github.com/npm/npm/releases/tag/v3.0.0
For upgrading the windows installation check out this package npm-windows-upgrade

How to add files in the RPM package of an Sailfish OS project?

I am trying to build a Sailfish OS app, and I need to use *.wav files, which are to be distributed through the *.rpm package. In my case, these files are to be put in /usr/share/[application_name]/sounds/*. How do I set up the *.pro and *.yamp files accordingly?
This isn't a RPM question per se: you seem to be asking how to configure
your application through *.pro and *.yamp if you deliver content in
*.rpm packages.
The packaging answer is: Patch the configuration files exactly the same
as if you were installing the *.wav files manually (i.e. not through *.rpm).
You will need to copy the *.wav content into the %buildroot tree that
is used to stage the files to be included in the package, as well as the
modified *.pro and *.yamp content. All the files to be included in the
*.rpm package will need to be mentioned in the %files manifest exactly
as they are to be installed (i.e. w/o the %buildroot prefix used for
staging files while building).
I finally found an answer!
I want to thank to the owner of that project:
https://github.com/krig/metronom-sailfish
From the .pro and the .yaml files of this project i found out how to deploy the files. First, we declare that constant:DEPLOYMENT_PATH = /usr/share/$${TARGET} which seems to hold the path to /usr/share/[appname]. Next, we define some kind of a variable (TODO: find a more detailed explanation of that). The definition of that first sets the path to the files, for example, data.files = data (the second data is the folder). Next, we set data.path to $${DEPLOYMENT_PATH}. We list all the files in OTHER_FILES and add the setting, in our case, data, to INSTALLS. Now, that we are finished with the .pro file, we move to the .yaml file for the .rpm and we add to the necessary line to the Files: section, in our case, - '%{_datadir}/%{name}/data', the last being the folder we need to add. TODO: to whoever is more experienced, please provide a more detailed answer.
Did you check https://sailfishos.org/develop-packaging-apps.html carefully? May helps.

How to include a folder when serve the project

i generated the scaffold of a famo.us project with Yeoman (yo famous)
i set up i small working project
i tried to launch it with 'grunt serve' command
it all works but no image is loaded because the folder content/images is not loaded
how can i include it?
thanks
I'm Myles the author of the Famous-Generator. The images in '/content/images/' should be able to be loaded as an absolute or relative path... although I have just updated the generated 'main.js' to use an absolute path for the sake of being explicit.
Remember that when you famous code is run it will be running inside of index.html, and therefore have the same "relative path" for included assets. As well, since you are serving via a development server, you are able to reference anything with absolute paths relative to the root directory of the project.
You should not have to touch requireConfig at all to be honest. It is only used to add vendor code installed in 'lib' to your path within require so you can reference modules by name rather than path. 'underscore' rather than '../lib/underscore'. This becomes nice as you begin to nest folders and don't want to have to manage relative paths. This also makes your code a lot more portable!
A nice sidebar, you should install all vendor code with 'bower install --save $LIB_NAME'. This will save the library / version to your bower.json and inject the path for the module into you requireConfig. Basically you can bower install anything and just start requiring!
yo famous is working just fine!
it was my mistake to try to set relative paths inside requireConfig including images: that is not working but i don't know if it is supposed to!
you have to use relative paths for every image and everything will be ok!

Resources