I am using Visual Studio 16.3.10, because I udpated 16.4 Preview 4 to Preview 6 and it seemed to cause serious problems. So I uninstalled it and went back to the released version. Then I installed the RAD Tool (2.1).
My project is ASPNETCore MVC v8.0
I have just discovered that the RAD tool is now producing sections of javascript that gulp rejects. As far as I can tell the offending code is in the datatable listAction in the generated index.js, where it is defining the inputFilter parameters for the query. It looks like it is putting placeholders in and not substituting values.
Original code (produced previously by RAD tool):
var dataTable = _$productsTable.DataTable({
paging: true,
serverSide: true,
processing: true,
listAction: {
ajaxFunction: _productsService.getAll,
inputFilter: function () {
return {
filter: $('#ProductsTableFilter').val(),
codeFilter: $('#CodeFilterId').val(),
nameFilter: $('#NameFilterId').val(),
chemCheckFilter: $('#ChemCheckFilterId').val(),
minMultiPartyMeetingsFilter: $('#MinMultiPartyMeetingsFilterId').val(),
maxMultiPartyMeetingsFilter: $('#MaxMultiPartyMeetingsFilterId').val(),
midpointReviewFilter: $('#MidpointReviewFilterId').val(),
finalReviewFilter: $('#FinalReviewFilterId').val(),
progressReportsFilter: $('#ProgressReportsFilterId').val(),
programTypeNameFilter: $('#ProgramTypeNameFilterId').val()
};
}
},
Code being produced now:
var dataTable = _$productsTable.DataTable({
paging: true,
serverSide: true,
processing: true,
listAction: {
ajaxFunction: _productsService.getAll,
inputFilter: function () {
return {
filter: $('#ProductsTableFilter').val(),
{{Dp_Property_Name_Here}}Filter: $('#CodeFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#NameFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#ChemCheckFilterId').val(),
minMultiPartyMeetingsFilter: $('#MinMultiPartyMeetingsFilterId').val(),
maxMultiPartyMeetingsFilter: $('#MaxMultiPartyMeetingsFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#MidpointReviewFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#FinalReviewFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#ProgressReportsFilterId').val(),
minConsultationsFilter: $('#MinConsultationsFilterId').val(),
maxConsultationsFilter: $('#MaxConsultationsFilterId').val(),
minHoursFilter: $('#MinHoursFilterId').val(),
maxHoursFilter: $('#MaxHoursFilterId').val(),
{{Dp_Property_Name_Here}}Filter: $('#MoodleAccessFilterId').val(),
programTypeNameFilter: $('#ProgramTypeNameFilterId').val()
};
}
},
It seems the int data types have their filter names, but the string and bool data types have this {{Dp_Property_Name_Here}} placeholder instead.
It seems this is what causes npm run build to throw an error:
npm : [[90m22:27:44[39m] 'build' errored after 3.41 s At line:1 char:1 npm run build
- CategoryInfo : NotSpecified: ([[90m22:27:44...ed after 3.41 s:String) [], RemoteException
- FullyQualifiedErrorId : NativeCommandError [[90m22:27:44[39m] [31mSyntaxError[39m in plugin "[36mgulp-uglify-es[39m" Message: Unexpected token: punc ({) Details: filename: Index.js line: 48 col: 5 pos: 1747 domainEmitter: [object Object] domain: [object Object] domainThrown: false
I can confirm that when I replace the {{Dp_Property_Name_Here}} with the appropriate filter name, I can then run npm run build.
So this is now a manual step I need to take any time I run the RAD tool. Any help to resolve it will be appreciated.
Any ideas how I can overcome this?
I know this is closed two years ago, but for those (like me) finding this solution from a search...
The solution above did not work for me, and I was also reluctant to edit the ModalManager.js in case a future upgrade of ASPNETZERO reverted my change.
So I did this in my CreateOrEditModal.js file, in the "this.init" function, right after invoking summernote():
$('.note-editing-area').keydown(function (e) { if (e.which === 13) { e.stopPropagation(); } });
Because SummerNote uses the note-editing-area class for its text input box.
I am exploring the new Customizable Dashboards and I'm excited about implementing this feature.
I noticed that if my user does not have the AppPermissions.Pages_Administration_AuditLogs permission, the dashboard does not get populated and they have no widgets available. (I note the generalStats widget adds the AppPermissions.Pages_Administration_AuditLogs to its permissions but I can't see why that would cause a problem).
I managed to work around this in the short term by adding the AppPermissions.Pages_Tenant_Dashboard permission to the AuditLogAppService, but I couldn't see exactly where this dependency was introduced. Of course, my workaround is not ideal, so maybe someone can identify the root cause.
Also a question: I am looking at setting up a library of widgets as partial html files, which are inserted at runtime. But is this something you guys are planning to develop soon? If so I'll hold off and just keep using the pattern you have set up so that upgrades are simpler.
It's up! Version 8.0 with Core 3.0 support is available for download.
I just downloaded the v8.0 project and all went smoothly. Thanks team, I've been waiting for this so that I can add my OData support!
On further searching I found this fiddle: https://dotnetfiddle.net/1ganYd, which gave me the pieces that seem to work, no installation packages required!
I have everything in the .html file at the moment and the calendar appears, so now I'll put everything in the right places.
Leaving this here in case anyone else needs it.
Apparently ASPNetZero used to include meronic's Calendar control but no longer includes it. Is this correct?
If so, how do I install https://fullcalendar.io/ into my MVC DontNet Core v7.2.0 project?
I have tried a bunch of things from instructions I found online. The instructions I found seemed to assume things that were not valid in my project and I didn't know how to resolve the issues. It seems the instructions all assume Angular.
Can someone provide steps that will suit my project?
Perfect! Thank you.
Angular wasn't what I needed - I'm creating a data transfer client, not a UI. But in the article you linked to, this was precisely what I hoped for:
AbpAspNetCore().DefaultWrapResultAttribute.WrapOnSuccess = false;
When querying the App Services as an API call, the return object looks like this:
{ "result": { -The serialized POCO object Swagger is advertising- }, "targetUrl": string, "success": bool, "error": string, "unAuthorizedRequest": bool, "__abp": bool }
While it's easy enough to unwrap the object once you know what to expect, unfortunately the auto-generated client code created by the Swagger/NSwag tool creates code which is broken because it is not expecting the wrapper. This means if I regenerate the client code I need to go through it fixing the deserialisation routines again.
Can we somehow tell Swagger to include the wrapper object in its advertised schema? This would mean the generated code would automatically have the correct objects to deserialise correctly (It would also mean Swagger reports its schema truthfully, which seems desirable).
This is now resolved.
The errors arose because none of the minified .js files were on the app service. I'm guessing that's what NPM does, but i don't know why I wasn't getting them deployed.
In the end I found that, although I thought it not relevant, I had some differences in my pipeline from the configuration in https://docs.aspnetzero.com/en/aspnet-core-mvc/latest/Setting-Up-an-Azure-Pipeline-Mvc-Core
When I went back and set mine up precisely as that document recommends it works.
I had used the Pipeline created by Visual Studio "Configure Continuous Depoyment", and adapted it. It uses different tools for the build and test, so there must be some difference there.
tl;dr: it's resolved.
This one is resolved now.
I updated Microsoft.NET.Test.Sdk to 16.3.0 (from 16.2.0). This changed the error messages, which led me to the solution. The wildcard selection of DLLs in the Azure test selection picks up xUint DLLs as well. Changing the selection is the solution, which I learned from this advice https://xunit.net/docs/getting-test-results-in-azure-devops
I found that I could not figure out what all the exclusions would need to be (The ones listed in that website didn't seem sufficient), so instead I explicitly specified the MyProjectTests.dll file without a wildcard.
Unit tests now run in Azure.