Fake build unable to get desired Zip file structure - f#-fake

I want to create a zip file from a .net core web app publish, the app is currently published to an _artifacts/MyApp folder, but I don't seem to be able to create the desired zip file structure.
The published output is the standard for any aspnet core app
_artifacts/MyApp
_artifacts/MyApp/wwwroot
_artifacts/MyApp/<dlls, config and other output>
And I wat the root of MyApp to be the root of my zip file, that is something like
/wwwroot
/<dlls, config and other output>
I tried with the following but it includes the folders _artifacts/MyApp inside the zip and I don't know where I'm doing it wrong or if it's possible to do it with this tool
[ !! "_artifacts/MyApp/*"
|> Zip.filesAsSpecs "_artifacts/MyApp"
|> Zip.moveToFolder ""
]
|> Seq.concat
|> Zip.zipSpec "Deploy.zip"
As far as I understand the docs, the key parameter is the workingDir on Zip.filesAsSpecs on https://fake.build/apidocs/v5/fake-io-zip.html

For that purpose you can use Zip.zip function in the same module:
Zip.zip workingDir fileName files.
In this case it would be something like
Zip.zip deployDir "Deploy.zip" !!(deployDir + #"\**\**").

Related

AWS Lambda package-deployed functions require() of a relative path, not found

I have a zip file containing the following structure (this is the root of the archive, not nested in a top-level folder, which I understand is a common cause of errors for aws-s3-lambda deployments):
- support/
- shared.js
- one.js
- two.js
and then in one.js and two.js:
var shared = require("./support/shared");
// ...
When I run this code locally, it works. I use the aws-sdk to upload the zip file to AWS-S3 and then use aws.lambda.createFunction() to create a function with that name and handler and everything. The created function DOES show up in my Lambda dashboard, but when I test it, I get "Cannot find module './support/shared'". I have also tried var shared = require("./support/shared.js"); and that gives "Cannot find module './support/shared.js'".
This is for runtime node6.10. The filename cases are correct for case-sensitive lambda.
Shouldn't this work?? What's the gotcha?
Is there a way to verify the file structure that Lambda is working in to show that the additional ./support/shared.js file actually made it to the working directory or whatever it uses?
The gotcha is that the zip file created on a windows machine has the wrong chmod permissions set in it for when AWS unpacks it. The files are there, but inaccessible but node just gives a generic warning about not found instead of that the folder access is denied.

Get XML comments output file location for ASP Core

I've added Swashbucklepackage to my ASP Core project.
I'd like to configure Swagger to use auto-generated by VS xml comments.
The problem is that I can't find the way to get that location:
PlatformServices.Default.Application.ApplicationBasePath - points to the project root path
Directory.GetCurrentDirectory() - the same
Path.GetFullPath(".") - the same
IHostingEnvironment.WebRootPath - the same
Output folder configured in <project>.xproj by BaseIntermediateOutputPath option.
But I can't get this location in runtime.
var pathToDoc = "????";
options.OperationFilter(new Swashbuckle.SwaggerGen.XmlComments.ApplyXmlActionComments(pathToDoc));
Bad solutions I see:
add configuration option to AppSettings.json
Relative path from project path (as I'm configuring bin output path).
But I'd like to use this with Docker, CI, localhost, so I don't think this would be the best solution to use hard-coded solution..
You can try the following function to get the XML File path
private string GetXmlCommentsPath()
{
var app = PlatformServices.Default.Application;
return System.IO.Path.Combine(app.ApplicationBasePath, System.IO.Path.ChangeExtension(app.ApplicationName, "xml"));
}
The xml file has the same name as the app. I am currently using this code in my project and it works fine.

Error after publishing .net web project

I am publishing a project in my local computer, I am getting an error because of the path of the files, in my project I am using relative path, but when i published the project I specified a Site/application so I put: localhost/myapp, but then, after the login the additional name myapp make it loses the path references, do you have any idea how to go through this?
I encountered the same problem with my web application this problem occurs because in your application you are hardcoding paths for ex :- /Home/Index or something which creates problems whenever you want to provide paths use helpers like #Url.Action(),#Html.Action(),#Url.Content() as shown below :-
#Url.Action("Index","Home",new{//specify route parameters here//})
If you are using areas in you application then specify it as :-
#Url.Action("Index","Home",new { area="myarea" })

Can't select all .hbs files in subfolders on windows

I want to precompile my ember templates. I installed an application for that, but I can only precompile one file.
I need like to select all files with .hbs extension including subfolders
I tried ember-precompile "components/**/*.hbs" -f precompiledTemplates.js
I get error saying
Error: ENOENT, no such file or directory 'components\**\*.hbs'
How do I say the program to look for .hbs files in all subfolders ?
I figured it's probably not a windows problem, but a limitation of the library I wanted to use(ember-precompile).
Instead I chose to use gulp which works well https://www.npmjs.org/package/gulp-ember-handlebars
Here's my coffeescript gulpfile for precompiling ember templates. After initiating gulp, it compiles my templates, and if one of templates changes, gulp recompiles.
gulp = require("gulp")
concat = require("gulp-concat")
handlebars = require("gulp-ember-handlebars")
gulp.task( "default", ["precompile-ember-templates"], ()->
# default tasks complete
)
gulp.task( "precompile-ember-templates", ()->
console.log("recompiling templates")
gulp.src( ["client/components/**/*.hbs"] )
.pipe( handlebars({outputType: 'browser'}) )
.pipe( concat("templates-compiled.js") )
.pipe( gulp.dest("client/public/") )
)
gulp.watch( "client/components/**/*.hbs", ["precompile-ember-templates"] )
There does seem to be a limitation within the Ember-Precompile code when handling the windows file structure and wildcards.
When running ember-precompile on windows you must do so through a cygwin terminal or similar (in my case I use git bash).
As an example in git bash when I type the line below in my project folder it works for me:
ember-precompile templates/*.handlebars -f templates/templates.js

F4 IDE gives "Invalid Uri scheme for local file" when running Fantom app

I started a very simple project using Xored's F4 IDE for Fantom. The first few times I ran it there was no error, but I started adding dependencies (fanbatis) and at some point the error below starting showing up every time I run a test or a dummy Hello World app.
[23:44:18 22-Nov-13] [err] [pathenv] Cannot parse path: C:\dev\f4workspace\auth\bin\fan
sys::ArgErr: Invalid Uri scheme for local file: c:\dev\f4workspace\auth\bin\fan/
fan.sys.LocalFile.uriToFile (LocalFile.java:64)
fan.sys.File.make (File.java:26)
util::PathEnv.parsePath (PathEnv.fan:47)
fan.sys.List.each (List.java:555)
util::PathEnv.parsePath (PathEnv.fan:43)
util::PathEnv.make$ (PathEnv.fan:22)
util::PathEnv.make (PathEnv.fan:20)
java.lang.reflect.Method.invoke (Unknown)
fan.sys.Method.invoke (Method.java:559)
fan.sys.Method$MethodFunc.callList (Method.java:198)
fan.sys.Type.make (Type.java:246)
fan.sys.ClassType.make (ClassType.java:110)
fan.sys.Type.make (Type.java:236)
fan.sys.Sys.initEnv (Sys.java:447)
fan.sys.Sys. (Sys.java:224)
fanx.tools.Fan.execute (Fan.java:28)
fanx.tools.Fan.run (Fan.java:298)
fanx.tools.Fan.main (Fan.java:336)
Hello, World!
It is more a nuisance at the moment because the tests and the dummy app still run. I created another project, copying all the source code adding class by class and testing after each change and the error never occurred. Any ideas please?
That's an interesting issue!
tl/dr: you have an empty project 'auth' in your workspace, either create some dummy class inside it or go to Run -> Run configurations, find your launch config and uncheck project without sources on 'Projects' tab.
In order to keep your Fantom installation clean from projects in a workspace, F4 puts built pods into project/bin/fan/lib/fan. When F4 launches projects from workspace, it uses PathEnv and builds FAN_ENV_PATH by joining paths to Fantom installation and bin/ folders in projects in workspace.
When Fantom runtime analyzes FAN_ENV_PATH, at first it interprets a path as native OS path, but if dir does not exist, it attempts to interpret it as file URI, here's relevant part of PathEnv source:
path.split(File.pathSep[0]).each |item|
{
if (item.isEmpty) return
dir := File.os(item).normalize
if (!dir.exists) dir = File(item.toUri.plusSlash, false).normalize
if (!dir.exists) { log.warn("Dir not found: $dir"); return }
The problem code is item.toUri – On Mac OS X and Linux this is parsed as an URI without scheme with path only, so if directory does not exist, this code just prints a warning in a console.
But on Windows, because of disk name in path, disk name is interpreted as scheme:
fansh> "C:\\Users".toUri { echo(path); echo(scheme) }
[\Users]
c
fansh> "/Users".toUri { echo(path); echo(scheme) }
[Users]
null
And then File constructor fails, because expects either 'file' scheme, or null scheme:
public static java.io.File uriToFile(Uri uri)
{
if (uri.scheme() != null && !uri.scheme().equals("file"))
throw ArgErr.make("Invalid Uri scheme for local file: " + uri);
return new java.io.File(uriToPath(uri));
}
I've created an issue here, so that F4 would automatically skip empty projects when building FAN_ENV_PATH – https://github.com/xored/f4/issues/25.
I thought the problem had something to do with the forward slash at the end of path as shown in this line of the error message
Invalid Uri scheme for local file: c:\dev\f4workspace\auth\bin\fan/
However, I found that such path didn't exist. I manually created both the bin and the fan folders and the error disappeared. To be honest I don't really know why F4 needs and checks for that folder because so far it hasn't written any file in it.