I want to create a file called config.js for the client end of my app, but it should be based on the environment. I've successfully done this for production using the tasks/register/prod.js file, but sailsjs does not seem to have an equivalent dev.js file.
I also can't find much information about this, so I'm hoping there is a standard workaround I'm just not thinking of.
I'm not sure why I found it so confusing, or why I never opened the README.md (duh!) in tasks/, but dev stuff goes in the default task (tasks/register/default.js).
ANSWER: README's are named as such for a very good reason.
Related
Let's say that I have two F# projects targeting NET5 and producing console applications. Let's call them MyService and MyAdminConsole. When I build the solution, then the folders, e.g. ...\MyService\bin\x64\Debug\net5.0 and ...\MyAdminConsole\bin\x64\Debug\net5.0 will contain:
...
appsettings.json
...
MyService.exe
MyService.dll
MyService.deps.json
MyService.runtimeconfig.json
MyService.runtimeconfig.dev.json
...
and
...
MyAdminConsole.exe
MyAdminConsole.dll
MyAdminConsole.deps.json
MyAdminConsole.runtimeconfig.json
MyAdminConsole.runtimeconfig.dev.json
...
where appsettings.json, obviously, exists only in MyService because it is the service, which needs the settings.
Now, I want to build both the service and the admin console into the same folder so that admin console could have access to the same appsettings.json and I stress the same appsettings.json, not a copy of it.
This seems straightforward, right? Just add a reference to MyAdminConsole into MyService project. However, when I rebuild the solution, then MyAdminConsole.exe and MyAdminConsole.dll are copied into ...\MyService\bin\x64\Debug\net5.0 but MyAdminConsole.*.json are not. Subsequently, MyAdminConsole won't work from that folder.
Sure, I can add post build steps and actually copy these json files where needed. However, that seems ugly and just plain wrong.
I wonder what is a proper solution? Thanks.
PS This is probably applicable to C# solutions as well but I have not checked that yet.
If I understand your issue correctly then please take a look at the workarounds proposed in https://github.com/dotnet/sdk/issues/1675
I have a SS3.x module that I have forked, pulled down from it's fork via composer, and started porting to SS4. So far so good, except when it comes to Requirements.
I'm using the Requirements format found in existing code in another module, which has a colon-separated format as follows:
Requirements::javascript('company/mymodule:javascript/SortableUploadField.js');
This file exists in the module at /vendor/company/mymodule/javascript/SortableUploadField.js. However on page load, I have a 404 in console as SS is looking for this file at /resources/company/mymodule/css/SortableUploadField.css. And this does not exist.
I added the following to my composer.json file for the module as I saw other modules doing this:
"extra": {
"installer-name": "sortableuploadfield",
"expose": [
"css",
"javascript"
]
},
And ran a composer update. But the /resources directory does not appear for this module (other modules are there). And I can't find any information online on how this is supposed to work.
Edit: As a sidenote, I wonder if the documentation for Requirements is misleading? It omits this caveat with modules and mention of the resources directory at all. If that documentation is meant only to convey the process for working with JS/CSS in normal mysite development, then it is just a bit confusing because the code samples us everywhere. Which wouldn't be a direct url to something in /vendor, surely.
Found this after tracing code that basically used the /resources directory. Short answer to my query is simply running
composer vendor-expose
This calls the VendorExposeTask that does this copying. The only other place I found this task being used is on VendorPlugin install method. So I assume that other than the above command, the only way SS actually does this on your behalf is on initial install of a module.
On a clojurescript project, I've needed to access contrib/externs/w3c_audio.cljs
I thought if I just wrote it in, google would access it, but I couldn't get that to work. Instead, I went in and just copied the file to my local directory.
Is there a way to not do that? i.e write something in my project.clj that knows I want to get the file in closure-compiler's contrib/externs?
:externs ["react/externs/react.js"
"externs/custom.js"
"node_modules/jquery/dist/jquery.min.js"
"contrib/externs/w3c_audio.js"
]
If your project doesn't use any other Clojurescript libraries that requires extra extern files, consider using fence.core/.. for javascript interop:
https://github.com/myguidingstar/fence
Even if your project does, fence still helps reduce number of extern files to work on
A web service client (WCF) is compiled as a DLL, then comes the dll into the folder "c:\windows\assembly" ... just like I can now say that my DLL in C:\client\client.dll.config is expected?
It would perhaps also the possibility that the program store directly, the problem is that it starts from a SharePoint workflow that is surely not quite that simple.
It may sound silly, but the problem sounds so simple ... Unfortunately I have found so far after a while no concrete solution to Find.
EDIT:
No idea? It is the despair, I am running out of time and I have so much work to implement all this, and such a ridiculous number of hours to keep me?
I've found a lot in terms of editing files, but I will not change it I will change only the access to another directory where the file is ...
In the proxy classes, we refer only so eager ...
[System.ServiceModel.ServiceContractAttribute
(Name = "_-ASD_-CAS01D0005P0000013203",
Namespace = "urn:sap-com:document:sap:soap:functions:mc-style",
ConfigurationName = "_ASD_CAS01D0005P000001320")
]
There must theoretically be possible to simply change the ...
I'm just trying to throw it somewhere in the folder of SharePoint, there is the program being started. The file is from "C:\Windows\system32\inetsrv" started, but on this directory, the dll probably does not have access, because I still get the same error as if there was no config file there.
The file is from "C:\Windows\system32\inetsrv" started, but on this directory, the dll probably does not have access, because I still get the same error as if there was no config file there.
Finally solved by
AppDomain.CurrentDomain.GetData ("APP_CONFIG_FILE");
I can not find it an addictive client.dll.config, but instead the web.config in SharePoint virtual directory "c:\inetpub\wwwroot\wss\Virtual Directories\80\" searches. I added the information there and it works fine!
Simple task, but for some reason no simple solution just yet.
We've all got web.config files - and I haven't worked anywhere yet that doesn't have the problem where someone yells across the room "Sh*t, I've just uploaded the wrong web.config file".
Is there a simple way of being able to auto generate a web.config file that will contain the right things for copying to release? An example of these being:
Swap connection string over to use live database
Change
Switch over to use the live/release logging system, and live/release security settings
(in our case we need to change the SessionState mode to InProc from StateServer - this isn't normal)
If you have others, let me know and I'll update it here so it's easy for someone else to find
Maintaining 2 config files works, but is a royal pain, and is usually the reason something's gone wrong while you're pushing things live.
Visual Studio 2010 supports something like this. Check it out here.
How are you deploying your builds. In my environment, this used to be a pain point too, but now we use cruisecontrol.net and script our builds in nant. In our script, we detect the environment and have different versions of the config settings for each environment. See: http://www.mattwrock.com/post/2009/10/22/The-Perfect-Build-Part-3-Continuous-Integration-with-CruiseControlnet-and-NANT-for-Visual-Studio-Projects.aspx for my blogpost onthe subject of using cruisecontrol.net for build management. Skip to the end fora brief description of how we handle config versions.
In my most recent project I wrote a PowerShell script which loaded the web.config file, modified the necessary XML elements, and saved the file back out again. A bit like this:
param($mode, $src)
$ErrorActionPreference = "stop"
$config = [xml](Get-Content $src)
if ($mode -eq "Production")
{
$config.SelectSingleNode("/configuration/system.web/compilation").SetAttribute("debug", "false")
$config.SelectSingleNode("/configuration/system.web/customErrors").SetAttribute("mode", "off")
$config.SelectSingleNode("/configuration/system.net/mailSettings/smtp/network").SetAttribute("host", "live.mail.server")
$config.SelectSingleNode("/configuration/connectionStrings/add[#name='myConnectionString']").SetAttribute("connectionString", "Server=SQL; Database=Live")
}
elseif ($mode -eq "Testing")
{
# etc.
}
$config.Save($src)
This script overwrites the input file with the modifications, but it should be easy to modify it to save to a different file if needed. I have a build script that uses web deployment projects to build the web app, outputting the binaries minus the source code to a different folder - then the build script runs this script to rewrite web.config. The result is a folder containing all the files ready to be placed on the production server.
XSLT can be used to produce parameterized xml files. Web.config being xml file this approach works.
You can have one .xslt file(having xpath expressions).
Then there can be different xml files like
1. debug.config.xml
2. staging.config.xml
3. release.config.xml
Then in the postbuild event or using some msbuild tasks the xslt can be combined with appropriate xml files to having different web.config.
Sample debug.config.xml file can be
<Application.config>
<DatabaseServer></DatabaseServerName>
<ServiceIP></ServiceIP>
</Application.config>
.xslt can have xpaths referring to the xml given above.
Can have a look at the XSLT transformation This code can be used in some MSBuild tasks or nant tasks and different web.config's can be produced depending on the input config xml files.
This way you just have to manage the xml files.
There is only one overhead that the xslt file which is similar to web.config need to be managed. i.e whenever there is any tag getting added in the web.config the xslt also needs to be changed.
I don't think you can 100% avoid this.
The last years of work ever and ever shows: where human worked, there are fails.
So, here are 3 ideas from my last company, not the best maybe, but better then nothing:
Write an batch file or an C#.Net Application that change your web.config on a doubleclick
Write a "ToDo on Release"-List
Do pair-realesing (== pair programming while realease :))