I'm setting up a REST server with web services on Drupal 7. I'm getting the error report:
The Spyc library could not be found
I downloaded the Spyc.php library (from https://github.com/mustangostang/spyc) and uploaded it to:
/sites/all/modules/services/servers/rest_server/lib/
And also tried putting it in /servers/rest_server/lib/Spyc/, but I still get the error.
The answer above appears to be out of date.
Downloading spyc from the link above and placing in sites/all/libraries/spyc takes care of the problem. No changes to capitalization are necessary.
The Services module documentation is not accurate!
...Once downloaded you need to add spyc.php to the rest_server/lib folder which exists under
the location you have installed services in.
You simply need to create a spyc folder containing spyc.php and place it in the sites/all/libraries, as should be expected with any external libraries.
Related
I created a new .NET 6 Blazor Server-side project and made a couple of changes. I have a couple of files using CSS isolation (like Contact.razor + Contact.razor.css).. In the _Layout.cshtml page the template added the following:
<link href="CustomerPortal.styles.css" rel="stylesheet" />
Where CustomerPortal is my Project Name. I can see the file is generated correctly under "CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\projectbundle\CustomerPortal.bundle.scp.css" and "C:\Data\Git\WebApps\CustomerPortal\CustomerPortal\obj\Debug\net6.0\scopedcss\bundle\CustomerPortal.styles.css"
BUT when I run the project, both with Kernel or IIS Express, I get a 404 not found for the CSS, if I try to manually navigate to the CSS I also can't find it. Any ideas? My csproj doesn't have any flags that would affect it.
Edit:
There is a new extension as part of the minimal setup in .NET 7, and backported to newer versions of .NET 6 as well.
Both in .NET 7 and .NET 6 you can now do:
builder.WebHost.UseStaticWebAssets();
Old answer:
You've got a couple options here to resolve this depending on the approach you want to take. I think we've figured out why it's happening, but UseStaticWebAssets() seems to not be supported for the new minimal startup code. So, here's your options I can think of off the top of my head.
Migrate your code back to the "old" way of doing application startup. This is still a supported and completely valid approach as there's edge cases that aren't supported (like this one).
Pass a new WebApplicationOptions to the CreateBuilder() method and, depending on environment, look for the static files in a separate (and correct) location. See some examples here.
With the existing builder, check the environment and use the StaticWebAssetsLoader to load static web assets.
A complete example of #3
if (builder.Environment.IsEnvironment("Local"))
{
StaticWebAssetsLoader.UseStaticWebAssets(builder.Environment, builder.Configuration);
}
That being said - I'd imagine they'll plug this hole eventually and provide parity for UseStaticWebAssets(). You can see the progress of this effort in this open GitHub issue.
For anyone else...
I had the exact same issue with a .net 6 blazor server app. For me it came down to the fact that I had changed the project name but the reference to {project}.styles.css in _Layout.cshtml was still pointing to the old project name.
Simply updating {project} here to the correct project name fixed my issue.
When I encountered this error, it was because I'd named my MVC project with a hyphen: htmx-spike.
When I generated the project from a template (dotnet new mvc -o htmx-spike), the tooling renamed the namespace to htmx_spike—with an underscore instead of a hyphen, because hyphens aren't allowed in C# identifiers—and used that modified name as the CSS filename in _Layout.cshtml.
However, it turns out that in this case the CSS location actually still corresponds with the project name, with the hyphen. So the auto-generated code is incorrect, and was causing the 404 to be returned:
Once I renamed the file in the link element to the correct name with the hyphen, everything was fine.
I had the same issue with a component I imported from another project. I solved it by closing all instances of Visual Studio, deleting the hidden folder [.vs] from the project folder, and then restarting the project in Visual Studio. On restart, Visual Studio recreated that folder and imported CSS file(s) were included.
Is it possible to download complete solution from Ohloh? I am trying to implement elFinder in my asp.net web page, but I am unable to make it work. I am still getting "Unable to connect to backend" error. I have found a project on Ohloh, but I cannot see any download links for the complete solution, only for single files. Is it possible to download it in a single pack (zip/rar/tar)?
Ohloh does not actually host the sourcecode. Here's the CodePlex page for the elFinder: http://elfinderaspnet.codeplex.com/.
I think this might be an IIS7 permissions thing, but I'm tagging it with OpenWrap because I might be wrong. When I try to publish a wrap to an HTTP repository I get the following error:
PS C:\OpenWrapExamples\Ninject> o publish-wrap -Name Ninject -remote MyHttpRepo
# OpenWrap Shell 2.0.0.10
# Copyright © naughtyProd Limited 2009-2011
# Using C:\OpenWrapExamples\Ninject\wraps\_cache\openwrap-1.0.1.81349963\bin-net35\OpenWrap.dll (1.0.0.0)
Publishing package 'Ninject-2.2.0.85378492.wrap' to 'MyHttpRepo'
The repository OpenWrap.Repositories.Http.HttpRepositoryNavigator is read-only.
I've tried setting the permissions on the folder, but that doesn't work either.
If you just exposed an indexed-folder (one you added with file:///path/) as an IIS site, it will be read-only (as there's little we can do with that).
If you use OpenWrap 1.0, , you can simply add two remotes, one for the UNC path (so you can publish) and the other one for the http one (so you can read the content back).
If you use the upcoming OpenWrap 2.0.1, you can simply add both in one go
o add-remote http://server/ -publish file://server/path/to/share
If you want a repository writeable over HTTP, you can implement that feature yourself rather easily: have your index file at /index.wraplist, add an endpoint that support a POST with some content (that's the package), say at /upload, and add the following to your index.wraplist:
OpenWrap will then happily upload to an http endpoint.
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.
I am building my site with a web deployment project but the build fails with a number of errors all relating to the "#include virtual" directives in my master page.
The includes are necessary to import a set of centrally managed html template files.
Here is an example of the include directive and associated error:
<!-- #include virtual="/v3/sits/pdpdev/assets-templates/inc/head.html" -->
/PDPRegistration.csproj/Pages/ContentPage.Master(15):
error ASPPARSE: Failed to map the path
'/v3/sits/pdpdev/assets-templates/inc/head.html'.
The error for each included file actually appears multiple times. I'm not sure what is being mapped or why, but this was never a problem until I started using WDP (which I wanted to alter web.config depending on the build environment, among other things.)
The project is built locally on my PC and then copied to the web server via a mapped drive. I found a few solutions on the 'net involving IIS metabase - they weren't quite clear to me, and I'm not sure if they apply given how I build and deploy the project (that is, would I have to build on the same system as IIS in order to make use of the metabase?)
Can anyone suggest how I can get my project to build with WDP?
Although SSI's are available within the Framework, the preferred way of doing include is to wrap the content from the file into a User Control (.ascx) as per the MSDN documentation See also: support.microsoft.com/kb/306575