When I try to open a new viewmodel I'm receiving the following error:
Failed to load ViewModel for type EasyBudget.Core.ViewModels.GridCategoryViewModel from locator MvxDefaultViewModelLocator
It´s also shows:
No symbols found.
And shows that cannot find or open the PDB file.
My viewmodel:
public class HomeViewModel
: MvxViewModel
{
private Cirrious.MvvmCross.ViewModels.MvxCommand _listCommandCategory;
public System.Windows.Input.ICommand ListCommandCategory
{
get
{
_listCommandCategory = _listCommandCategory ?? new Cirrious.MvvmCross.ViewModels.MvxCommand(DoListCategory);
return _listCommandCategory;
}
}
private void DoListCategory()
{
ShowViewModel<GridCategoryViewModel>();
}
}
And my other viewmodel:
public partial class GridCategoryView : MvxPhonePage
{
public GridCategoryView()
{
InitializeComponent();
}
}
Does anyone knows what may I be forgeting?
Best regards
Wilton Ruffato Wonrath
I believe the problem will most likely be somewhere in the construction of the ViewModel:
perhaps the constructor itself isn't public?
perhaps one or more of the parameters for the constructor couldn't be found?
perhaps some code inside the constructor has thrown an exception
Where you posted 'my other viewmodel' you actually posted code only for your other view. Can you post the code for the ViewModel that accompanies that view?
If you enable your debugger to break on all Exceptions, then this will possibly help you to find the problem that occurs during loading (inside https://github.com/slodge/MvvmCross/blob/v3/Cirrious/Cirrious.MvvmCross/ViewModels/MvxDefaultViewModelLocator.cs).
If you want to a pdb for debugger symbols, then these can be found inside the folders of http://github.com/slodge/MvvmCross-Binaries - inside the VS2012/Release folders. We are also currently trying to work out how to distribute these via SymbolSource.org (first got the request/suggestion this week)
Finally, if you want to see trace from a Windows build and are using the release packages from nuget then you can do this by overriding CreateDebugTrace() in your Setup.cs file - e.g. try:
protected override IMvxTrace CreateDebugTrace()
{
return new MvxDebugTrace();
}
This will also allow you to add some debug trace to your Core code if you want to using:
Mvx.Trace(format, args...)
Mvx.Warning(format, args...)
Mvx.Error(format, args...)
Perhaps, you forgot about adding ViewModel type to your generic MvxPhonePage.
Try this:
public partial class GridCategoryView : MvxPhonePage<GridCategoryViewModel>
Related
When Excel tries to call a method in a abstract base class i get a Run-Time error
"Cannot run Marco 'MarcoName'. The macro may not be available"
I can run code from the super class.
The code is similar to this
public abstract class MyBaseClass
{
public static bool MyMethod(string path)
{
if(Valid(path))
{return true;}
return false;
}
}
This code is in a separate assembly imported via a nuget package
The calling code is similar to the below
public class MyClass : MyBaseClass
{
public static bool MyOtherMethod()
{
return true;
}
}
Marking the methods with the "[ExcelFunction]" attribute has no effect.
I am loading the xll file like so,
Application.RegisterXLL (path)
I call the method like so,
Application.Run("MyMethod", path)
Only code in assemblies that are included in the <ExternalLibrary ... /> list in the .dna file are scanned for functions to register. Maybe your external assembly is not mentioned there.
Also, abstract types were not always considered. It looks like this changed at some point, if I look at the code that scans the assemblies here: https://github.com/Excel-DNA/ExcelDna/blob/57c2d0a499a044f6cd1c4ae2c9fbf5b084159dea/Source/ExcelDna.Integration/AssemblyLoader.cs#L93
So it might depend on your Excel-DNA version too.
Easiest might be to have a class with all the functions you want to export, where you can add the Excel-specific attributes (<ExcelFunction .../>) and just forward the calls internally.
I'm one of the many windows app developers. I'm sure someone other ran in this problem too. I want to have a base page (c#) where I add methods and use it in some pages without coding it over and over.
I've tried it like this:
Basicpage.cs:
public class BasicPage : Page
{
public void Test() {
}
}
SettingsPage.xaml.cs:
public sealed partial class SettingsPage : BasicPage{
public SettingsPage () {
InitializeComponent();
}
}
On the bold "BasicPage" there are the errors:
Base class of "...SettingsPage" differs from declared in other parts
and
Base type 'BasicPage' is already specified in other parts
Does someone know a solution?
I assume SettingsPage has a XAML part, which also needs to be derived from BasicPage:
<local:BasicPage x:Class="MyNamespace.SettingsPage" ...>
<!-- settings page content -->
</local:BasicPage>
I get this error when opening one specific form. The rest is working fine and I have no clue why this one isn't.
Error: An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext. This is not supported.
I get the error at _oDBConnection when I try to save. When I watch _oDBConnection while running through the code, it does not exist. Even when I open the main-window it does not exist. So this form is where the DataContext is built for the very first time.
Every class inherits from clsBase where the DataContext is built.
My collegue is the professional one who built it all. I am just expanding and using it (learned it by doing it). But now I'm stuck and he is on holiday. So keep it simple :-)
What can it be?
clsPermanency
namespace Reservation
{
class clsPermanency : clsBase
{
private tblPermanency _oPermanency;
public tblPermanency PermanencyData
{
get { return _oPermanency; }
set { _oPermanency = value; }
}
public clsPermanency()
: base()
{
_oPermanency = new tblPermanency();
}
public clsPermanency(int iID)
: this()
{
_oPermanency = (from oPermanencyData in _oDBConnection.tblPermanencies
where oPermanencyData.ID == iID
select oPermanencyData).First();
if (_oPermanency == null)
throw new Exception("Permanentie niet gevonden");
}
public void save()
{
if (_oPermanency.ID == 0)
{
_oDBConnection.tblPermanencies.InsertOnSubmit(_oPermanency);
}
_oDBConnection.SubmitChanges();
}
}
}
clsBase
public class clsBase
{
protected DBReservationDataContext _oDBConnection;
protected int _iID;
public int ID
{
get { return _iID; }
}
public DBReservationDataContext DBConnection
{
get { return _oDBConnection; }
}
public clsBase()
{
_oDBConnection = new DBReservationDataContext();
}
}
Not a direct answer, but this is really bad design, sorry.
Issues:
One context instance per class instance. Pretty incredible. How are you going to manage units of work and transactions? And what about memory consumption and performance?
Indirection: every entity instance (prefixed o) is wrapped in a cls class. What a hassle to make classes cooperate, if necessary, or to access their properties.
DRY: far from it. Does each clsBase derivative have the same methods as clsPermanency?
Constructors: you always have to call the base constructor. The constructor with int iID always causes a redundant new object to be created, which will certainly be a noticeable performance hit when dealing with larger numbers. A minor change in constructor logic may cause the sequence of constructor invocations to change. (Nested and inherited constructors are always tricky).
Exception handling: you need a try-catch everywhere where classes are created. (BTW: First() will throw its own exception if the record is not there).
Finally, not a real issue, but class and variable name prefixes are sooo 19xx.
What to do?
I don't think you can change your colleague's design in his absence. But I'd really talk to him about it in due time. Just study some linq-to-sql examples out there to pick up some regular patterns.
The exception indicates that somewhere between fetching the _oPermanency instance (in the Id-d constructor) and saving it a new _oDBConnection is created. The code as shown does not reveal how this could happen, but I assume there is more code than this. When you debug and check GetHashCode() of _oDBConnection instances you should be able to find where it happens.
Im started to learn TDD just now. And i have some troubles with testing my controllers. So, i will try to explain.
I have a controller:
public AccountController(IStoreService storeService)
{
_storeService = storeService;
}
public virtual ActionResult RenderBalance()
{
var model = _storeService.GetStorePageBalanceModel();
return PartialView("MyControl", model);
}
Here i want to test my RenderBalance action:
public class when_balance_renders
{
private static Mock<IStoreService> storeService = new Mock<IStoreService>();
private static AccountController controller;
private static ActionResult result;
private Establish context = () =>
{
controller = new AccountController(storeService.Object);
result = controller.RenderBalance();
};
private It should_be_not_null_result = () => { result.ShouldNotBeNull(); };
}
But this code doesn't work. I have this error on debug mode:
Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format.
How may i fix it? And can you give me some recommendations about testing controllers.
Thanks, Nogin Anton.
If you are just starting out with TDD, try a simpler approach like classical TDD as pointed out here http://martinfowler.com/articles/mocksArentStubs.html
Also if you have this error Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format.
There is something very basic setup wrong. Remove lines of code until you can at least compile, then move forward from there.
I'm getting an error when trying to run the EF 4.3.1 add-migrations command:
"The model backing the ... context has changed since the database was created".
Here's one sequence that gets the error (although I've tried probably a dozen variants which also all fail)...
1) Start with a database that was created by EF Code First (ie, already contains a _MigrationHistory table with only the InitialCreate row).
2) The app's code data model and database are in-sync at this point (the database was created by CF when the app was started).
3) Because I have four DBContexts in my "Services" project, I didn't run 'enable-migrations' command (it doesn't handle multipe contexts). Instead, I manually created the Migrations folder in the Services project and the Configuration.cs file (included at end of this post). [I think I read this in a post somewhere]
4) With the database not yet changed, and the app stopped, I use the VS EDM editor to make a trivial change to my data model (add one property to an existing entity), and have it generate the new classes (but not modify the database, obviously). I then rebuild the solution and all looks OK (but don't delete the database or restart the app, of course).
5) I run the following PMC command (where "App" is the name of one of the classes in Configuration.cs):
PM> add-migration App_AddTrivial -conf App -project Services -startup Services -verbose
... which fails with the "The model ... has changed. Consider using Code First Migrations..." error.
What am I doing wrong? And does anyone else see the irony in the tool telling me to use what I'm already trying to use ;-)
What are the correct steps for setting-up a solution starting with a database that was created by EF CF? I've seen posts saying to run an initial migration with -ignorechanges, but I've tried that and it doesn't help. Actually, I've spent all DAY testing various permutations, and nothing works!
I must be doing something really stupid, but I don't know what!
Thanks,
DadCat
Configuration.cs:
namespace mynamespace
{
internal sealed class App : DbMigrationsConfiguration
{
public App()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.App.Repository.Migrations";
}
protected override void Seed(.Services.App.Repository.ModelContainer context)
{
}
}
internal sealed class Catalog : DbMigrationsConfiguration<Services.Catalog.Repository.ModelContainer>
{
public Catalog()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.Catalog.Repository.Migrations";
}
protected override void Seed(Services.Catalog.Repository.ModelContainer context)
{
}
}
internal sealed class Portfolio : DbMigrationsConfiguration<Services.PortfolioManagement.Repository.ModelContainer>
{
public Portfolio()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.PortfolioManagement.Repository.Migrations";
}
protected override void Seed(Services.PortfolioManagement.Repository.ModelContainer context)
{
}
}
internal sealed class Scheduler : DbMigrationsConfiguration<.Services.Scheduler.Repository.ModelContainer>
{
public Scheduler()
{
AutomaticMigrationsEnabled = false;
MigrationsNamespace = "Services.Scheduler.Repository.Migrations";
}
protected override void Seed(Services.Scheduler.Repository.ModelContainer context)
{
}
}
}
When using EF Migrations you should have one data context per database. I know that it can grow really large, but by trying to split it you will run into several problems. One is the migration issue that you are experiencing. Later on you will probably be facing problems when trying to make queries joining tables from the different contexts. Don't go that way, it's against how EF is designed.