Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Commands: Better error when x64, ARM, or .NET Native #5839

Closed
bricelam opened this issue Jun 22, 2016 · 0 comments
Closed

Commands: Better error when x64, ARM, or .NET Native #5839

bricelam opened this issue Jun 22, 2016 · 0 comments
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone
1.1.0

Comments

@bricelam
Copy link
Contributor

If you run the commands on UWP project with .NET Native enabled on on any other project with a non-x86 platform, you currently get an error like the following.

Could not load assembly 'MyApp'. Ensure it is referenced by the startup project 'MyApp'.

We can make this better by either detecting .NET Native, x64, or ARM, or by adding more information if the startup project matches the target project.
@bricelam bricelam changed the title NuGet Commands: Better error when assembly is x64,ARM, or native NuGet Commands: Better error when x64, ARM, or .NET Native Jun 22, 2016
@bricelam bricelam changed the title NuGet Commands: Better error when x64, ARM, or .NET Native Commands: Better error when x64, ARM, or .NET Native Jun 22, 2016
@rowanmiller rowanmiller added this to the 1.1.0 milestone Jun 24, 2016
@nicolasparada nicolasparada mentioned this issue Jun 30, 2016
Closed
@rowanmiller rowanmiller removed the pri0 label Jul 6, 2016
natemcmaster pushed a commit that referenced this issue Aug 10, 2016
Show warning when architecture is not in {x86, x64, AnyCPU}
f55b1d1 
Continue to execute on 'ef.exe' and hope for the best. :)

Fix #5839
@natemcmaster natemcmaster mentioned this issue Aug 10, 2016
Merged
natemcmaster pushed a commit that referenced this issue Aug 11, 2016
Split tools into VisualStudio and DotNet packages and implement ef.exe
9cc12d6 
Issues:

 - Fix #646 - implements assembly-based command line interface
 - Fix #5273 - Split tools packages into .Tools.DotNet and .Tools.VisualStudio
 - Fix #5334 - Refactor cmdlets/dotnet-ef to invoke ef.exe/ef.dll
 - Fix #5684 - Use nuspec's instead of Sake
 - Fix #5839 - throw warning when architecture is not in {x86, x64, AnyCPU}

Other changes:

 - Add --no-color and --no-appdomain to command line tools
 - Add --json option to 'dbcontext scaffold' and 'migrations remove'
 - Refactor the inside-man invocation for Tools.DotNet to use "ef.dll" instead of invoking .Design.exe.
 - Add native powershell module for processing/forwarding streams
 - Reorganize code
    *  💔 break up DotNet and VisualStudio command line tools into separate packages
    * Push down execution logic dode from Tools.VisualStudio into .Design.
    * Lift code from .Design.Core to .Design
    * Reorganize test projects
    * Create a powershell only project for Tools.VisualStudio
    * Move tests into appropriate test projects and adjust namespaces
@natemcmaster natemcmaster added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Aug 12, 2016
@ajcvickers ajcvickers modified the milestones: 1.1.0-preview1, 1.1.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Milestone
1.1.0
Development

No branches or pull requests
4 participants
@bricelam @ajcvickers @natemcmaster @rowanmiller