web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Finance | Project Operations, Human Resources, ... / How can I reuse Packag...
Finance | Project Operations, Human Resources, ...
Unanswered

How can I reuse PackageLocalDirectory workspace mappings in separate projects within the same environment?

(0) ShareShare
ReportReport
Posted on by Carmelo Paz

I was wondering if there is a way to map C:\AOSService\PackageLocalDirectory\ in different workspaces of the same virtual environment.

For example, I create an organization called CPProjects in Azure DevOps, then create two separate projects called CPFleetManagement and CPAccountsReceivable respectively. These two projects are unique and different from each other, and will have their own solution files in the VM (CPFleetManagement.sln and CPAccountsReceivable.sln respectively).

If I do a workspace mapping for CPFleetManagement and link it to Azure DevOps, everything is good (server/local mapping would be Projects = */CPFleetManagement and Metadata = C:/AOSService/PackageLocalDirectory).

When I do the same mapping for CPAccountsReceivable, Visual Studio will throw an error saying the folder PackageLocalDirectory is already mapped in the previous workspace. Deleting the workspace mapping for CPAFleetManagement is off the table, since I'll need the mapping there to check in code for CPFleetManagement.

Is there a way to map the PackageLocalDirectory to the second project without resorting to deleting the previous workspace mapping?

I have the same question (0)
  • Martin Dráb Profile Picture
    Martin Dráb 237,967 Most Valuable Professional on at

    What you're trying to do is indeed wrong. Before we can suggest a solution, we need to understand your situation, but your description is confusing.

    You mentioned some Visual Studio solutions, but it's irrelevant to the mapping of PackageLocalDirectory.

    Are you talking talking about a single team project in Azure DevOps or two team projects? If two, does it mean that you're trying to use a single Dev environment for two F&O implementations and switch between them on demand? If so, is it really a good idea?

    If it's about a single team project, why do you want two mappings? Doesn't it just mean that you need two modules, one for CPFleetManagement and one for CPAccountsReceivable?

  • Carmelo Paz Profile Picture
    Carmelo Paz on at

    I apologize if this post comes off as confusing and I’ll try my best to clarify what I want to do.

    I have my own virtual environment assigned to me. I use this for training. Its completely fine to mess up this box. At the end of the day, we just need a remote repository to check in all customizations so our senior devs can review the code. We also want to collect all the code we’ve done into one organization in Azure DevOps, wherein each module will have its own unique project contained within it.

    Going to the VM side of things, we create different customizations in code and save them as different solution files in the local directory (for example CPFleetManagement.sln and CPAccountsReceivable will contain code for their own modules). Since the senior dev has access to the VM, it’ll be pretty convenient for him if all solution files can be reviewed in one, single F&O implementation. Again, all of this is just for training and review purposes.

    We want to take the code and all customizations we’ve done and save them to Azure DevOps for review. If we go back to my sample organization CPProjects, I want CPProjects to contain the solution files for CPFleetManagement.sln and CPAccountsReceivable.sln, maintained inside their own, unique projects in Azure DevOps, ProjectOne and ProjectTwo respectively. I can do all these on my end.

    The problem arises when I do a mapping in Visual Studio for any of these local projects. If I map PackageLocalDirectory to the Metadata folder in ProjectOne, I won’t be able to map PackageLocalDirectory to the Metadata folder in ProjectTwo. And since I need to check in code for both projects, deleting any mapping is not an option.

    I hope I clarified things. Perhaps there’s a better way of doing the above?

  • Martin Dráb Profile Picture
    Martin Dráb 237,967 Most Valuable Professional on at

    Hmm, you're saying that you want to have several team projects, which sounds like a very strange idea. Also, you said that "it’ll be pretty convenient for him if all solution files can be reviewed in one, single F&O implementation", but you want to do the opposite. Why?

    Note that what projects and solutions you have in Visual Studio isn't related to the mapping of PackageLocalDirectory. You're also wrong in thinking that Visual Studio solutions contain code. They merely refer to code stored in PackagesLocalDirectory.

    Why exactly don't you want to have a single repository with two packages, CPFleetManagement and CPAccountsReceivable? Wouldn't it meet all the requirements you mentioned?

  • Carmelo Paz Profile Picture
    Carmelo Paz on at

    I see. The idea behind having several team projects is a stylistic choice. But after reading your reply, I’ve realized my method is a convoluted way of getting things done. Thank you for clarifying.

    I guess its better than to just have one workspace mapping for the VM, and tie that to a single project in Azure DevOps.

  • Martin Dráb Profile Picture
    Martin Dráb 237,967 Most Valuable Professional on at

    Creating a separate a team is basically saying "here I have a completely separate implementation for something else, with a separate set of teams and users, a different security setup, an unrelated code repository, a different set of work items, possibly a comletely different workflow...

    That's not your case. All your changes belong to the same training project, with the same security setup and so on. If you wanted, you could put your solutions to two separate code folders or branches, which would make them completely independent, but this still doesn't need multiple team projects. And you don't seem to have such a requirement either, therefore a single branch and a single workspace is all you need.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 456 Super User 2025 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 429 Most Valuable Professional

#3
BillurSamdancioglu Profile Picture

BillurSamdancioglu 239 Most Valuable Professional

Last 30 days Overall leaderboard

Featured topics

End-of-life Announcement for Microsoft Dynamics GP

Product updates

Dynamics 365 release plans